Slashdot Mirror
Let's Make UNIX Not Suck
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.
So if the CORBA server breaks, the whole system is useless. At 3 am, when the system will only come up in single user mode, and ORBit wont run...what do you do?
/etc themselves for you? so an experienced admin can still go in and change themn on his own?) then I think this must stay exclusivly in user application space.
;)
I have yet to see any adressing of this issue. Until it is properly adressed (perhaps just have objects that edit the files in
The Helix Setup Tools system Miguel talks about is basically a GNOME front end and a Perl backend to the standard system configuration scripts. This new system does in NO way affect your ability to manually edit these files.
In fact, Miguel propses that the Helix Setup Tools store all their data in XML files and that you could easily revert back to, say, the settings you used last week, with only a few clicks. Sounds better than editing some obscure configuration file at 3 am doesn't it?
This doesn't make it any less cool. Its just not a panacea, like it sounded like this talk was trying to make it out to be.
Maybe BONOBO isn't an panacea, but it's still damn cool and I *really* hope it does take off big time.
For a nice HomeSite clone:
Quanta.
It rocks...very nicely done, and modular to boot.
I use it on several sites.
"Don't try to confuse the issue with half truths and gorilla dust."
Bill McNeal (Phil Hartman)
You can write an application however you want for MacOS, but they still have a UI standard that most developers try to follow and the users are probably better off for it (though they hate non-comforming apps as a result). I don't think anyone's suggesting you FORCE people to adhere to these things, but as it stands now UNIX doesn't even have these kinds of standards. How would they hurt?
If you want to use some little GNOME program, you run the helix-code installer. It finds and downloads all the libraries you needs, finds a place for them and installs them.
That's one amazing piece of software. It actually makes your harddrive larger? What'll they think of next.
There's this wonderful thing called "library versioning" -- when you install a newer library, that doesn't mean all your apps can't still use the old one.
Used to be, anyway. But there's no way I'm installed eighty-eleven libraries the hard way. I'm gonna find RPMs. And RPM -U removes the old lib. Whoops.
--
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
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?
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Why does anyone care what OS grandma is going to use on her web-pad? It's like arguing about the curtains on an oil rig. Forking for the sake of desktop market share will only serve to weaken the elements that made it strong to begin with.
[posted from an IRIX box]
www.ridiculopathy.com
Unix may be modular but that does not matter, it is not standardized. Every single configuration file has its own syntax, every text editor their own key bindings. Besides, command line tools can not do the type of integration needed. The real advantages of COM are just starting to show up in windows. It was a rough road getting there (which is the scariest part for linux I think) but w2k is really getting its act together. Once the bugs are worked out, w2k is almost there, it is going to be incredible what you can do. Miguels example of ie and COM should make it clear to anyone, any program can use any renderer ect that ie has to offer, or any other program in windows. With open source, it could be even better. Imagine taking only the best parts from existing applications and actually have it work with minimal effort. Piped text is great and all but its limitations are obvious. MS bit the bullet and moved everything over to COM, and its just starting to pay off.
PS: Check out ROX-Filer. It is the first gui file manager that Ive liked better than strait cli. Maybe it's because of how well it integrates with the cl, but I encourage people to give it a try. It is the fastest one I've seen, up there with ls ;) Very well thought out efficient, I'm amazed.
Insufficient Coffee in Operator - System halted.
Sorry, got the band name wrong. That should read "Great Big Sea" (I always get it wrong), and the song is on their album "Up".
"The first time I got drunk, I got married. The second time I bought a chimpanzee, after that I stayed sober" Arian Seid
When you first load, for instance, directdraw, you get directdraw 1.0. You then specifically request the version you want. That way, as long as all versions are present, a program gets what it wants, not nessessarily the most recent verison.
Freedom's just another word for nothing left to lose
You are missing the point. CORBA does not implement policy, only a mechanism. This is policy on top of any object model you choose. That is why it is powerful.
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.
I agree that this probably doesn't provide maximum global utility, but in a free world you've got to live with people's choices. Also, your complaint is based upon the dubious assumption that all KDE/GNOME developers would be working on the other project if their's didn't exist.
2. Web Browser.
Agreed, linux is in big trouble here - but so is windows. We've basically got a one-browser world now. This is an amazingly bad situation to be in, considering how many people are browser users.
3. Mail Client.
Sorry, but you've got no defense here. Balsa, Mutt, even emacs will read mail. Gnome folks are even building an Outlook clone.
4. Editor. Uhh, I use vi and emacs when there is absolutely, positively, nothing else available. Don't get me wrong, I first learned emacs over 8 years ago. But there are some basic functions which I rely upon that don't exist in emacs. Give me something like HomeSite on a linux box and you've got a convert.
Try Screem.
5. Word and Excel.
Linux has no programs to match these. If you really need a good office suite, you should stick to windows.
I did write a whole section about the IE example but I've deleted it. If you think that's a way to get good software then you're too far gone for anything I can say to change your mind.
Finally, to answer your question about the ways in which Windows is better than Unix (Linux in my case):
For me, that's the whole list. Obviously - I wouldn't be using Linux if it wasn't better for me than Windows. My opinion is that anyone who uses Gnome or KDE should be using Windows; it is almost certainly better for what they want to do.
I used to hate Unix, until I started using Windows. I certainly agree that *nix sucks, but it sucks less than anything else on the market at the moment.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
If you want to use some little GNOME program, you run the helix-code installer. It finds and downloads all the libraries you needs, finds a place for them and installs them.
And for those of us who don't want to use the helix-code installer? Oh, that's right! We're screwed.
-Nathan
Well, it's a question of what do you want to accomplish....
Force your ideals on everyone or Make the industry, and unix as a whole, a better design?
Like it or not, i don't see the GPL world that RMS envisions as ever happening....
You wouldnt need to reconfigure your kernel. I've actually never needed to recompile the kernel (though its easy to do) The documentation is always update and accurate. I had no problem setting up ppp. I think they include a sample ppp.conf now, so it may be even simpler.
Drawing a parallel between Nazism and a widget set is a bit extreme.
But apparently, you're willing to subject yourself to a more extreme version of DLL Hell, seeing that you now have N times more files to track, N times the duplicated code, and G more wasted time tracking it all, where N is the number of widget sets, and G = N * Time wasted on each.
Reading some of the comments here, seems like people haven't really read what the article or don't really understand what Bonono is.
:
Check out the full description at
http://www.helixcode.com/tech/bonobo.php3
Just to quote from that page if you can't be bothered :
Bonobo is a set of CORBA interfaces that define the interactions required for writing components and compound documents. These CORBA interfaces are not bound to GNOME, the X11 windowing system, or the UNIX system.
The Bonobo distribution as shipped by the GNOME project includes the Bonobo CORBA interfaces, and a GNOME/Gtk+-based implementation of these interfaces.
I admint ignorance in this area - is this truly a problem for the community? Why is it so bad for someone (potentially a loser) to consider themselves a badass open source hacker? At it's worst its ignorable, at its best, these people might actually be learning something and might one day contribute.
What about Slackware?
Sticking feathers up your butt does not make you a chicken - Tyler Durden
Some might call that "learning how to code". Or perhaps the world would be a better place if everyone just knew how to build innovative apps from the get go.
No, I am praising emacs as having a scriptable interface. You can call an elisp function for any functionality of the program.
Scuttlemonkey is a troll
Isn't UNIX still (tm) AT&T? I thought the generic term was Posix...
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.
--
All right, O insightful one, let us assume for the sake of argument that you are 100% correct and that gnome is "controlled by" one company and the installer by another. As long as the source for both pieces are released under the GPL, what is the problem?
Hari.
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
Cheers
Jon
There are all sorts of things that you can expect to be able to do on any Unix-like OS. You expect X-Windows, NFS, vi, etc. Yet at one time or another most of the Unix "standards" had some sort of competition.
Miguel is proposing to standardize Linux (and Unix as well) simply by creating Free software that is so cool that it becomes ubiquitous. Instead of writing their own HTML widget, XML parser, Address book, text editor widget, etc. programmers will simply borrow the GNOME widgets. Programmers will do this because GNOME is free, comes with source code, and because GNOME can be installed anywhere.
GNOME will simply become one more layer in the existing framework that is UNIX. Some people won't use it in much the same way that some Linuxers don't use X-Windows. But most of the new software will happily use these shared components in much the same way that they happily use the existing shared Unix libraries.
Actually, I believe AT&T sold UNIX (including the trademark) to Novell, who later sold it to SCO. As far as I know, SCO still holds the trademark. (It was SCO that gave permission for the Lions book to be published with V6 UNIX source code in it...)
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
That is like a universal truth I had just come to accept until I found out about FreeBSD / Debian.
.8 days. *shudders*
RPM install dont work library problems
You are now library hunter, a legendary hunter of magical power devices taht make your programs work you will hunt in foreign countries (webservers) for arcane symbols and pattenrs(Gziped source files) to translate them int oa fuel source (compiling them) for your most masterful creation, the programn you wished to execute.
hmmn.. at least thats what I dreamed one night after setting up GNOME back in the
Then I woke up staring at some yellow n black xterm having a hard time telling which was the dream.
Jeremy
If you think education is expensive, try ignornace
"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"
Funny, all I've usually ever needed to do is download and install the program. If one already has GNOME installed, all the libraries that a GNOME program depends on are already there. I've never had problems with debugging apps because I just upgraded libraries.
Galeon is a poor example of a generic GNOME program. It is new and beta, and it depends upon Mozilla components as well as the GNOME libraries.
Offhand, you seem to be objecting to problems that for the most part don't exist.
Saying that CORBA's interface versioning solves this problem is like saying that a hammer solves the problem of nails. It's a tool, valuable to the extent that people know how to use it properly by making sure that the interface definition accurately and completely describes the behavior of a component and that the "actual interface" doesn't change without corresponding change to the "official interface" - something that doesn't just happen on its own. Arguably, what you really need to solve this problem (and, even more arguably, what some languages or programming models give you) is a way to ensure that all behavioral dependencies are captured in the interface definition and that nobody can even begin to depend on something that could change.
Slashdot - News for Herds. Stuff that Splatters.
Here is my point. It isn't just CORBA. Corba is a neat way to force applications to talk in a non-pointer determinate fashion. It's about the policy (that is what bonobo partially delevers).
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.
So what's the problem? What DOES suck is the attempt to make Unix into a friendly operating system. Great.....IF you know what you're doing.
The Microsoft Windows 95 interface is successful because they had Human/Computer interaction experts working to design the interface. (Don't start with the 'Microsoft copied Apple copied Xerox' crap. Each interface is different enough that SOME design went into it.) The problem here, is that we have the Gnome people, and the KDE people, etc., trying to make a Graphical Interface - and they're trying to be too much like the other interfaces out there, and the rest of the design is just being assumed.
UNIX doesn't suck. It was designed to be a powerful network operating system - and that's exactly what it is. Sure, 10 years down the road it's going to be different. However, the basic functionality will be the same.
To say an Operating System sucks because of bad design of an additional interface is ignorant.
-- Give him Head? Be a Beacon?
-- Give him Head? Be a Beacon? :P)
(If you can't figure out how to E-Mail me, Don't.
You're arguing 2 different things here. The first is that IE is big, bloated, unstable, etc. That I will agree with. The second is that COM sucks. Somehow, you managed to infer the second argument from the first.
The idea behind the COM model doesn't suck. It's actually much closer to the lots of small programs that do one things really well and then string them together model of *nix. But, as Miguel points out in the paper, the string small apps together idea falls apart at a certain level. Right now under *nix, most apps do everything themselves. Again as Miguel points out, why don't Apache, Sendmail, Bind, et al use some of the same routines. They are all network daemons. They can all use similar init routines, security routines, etc. But they don't, each one rewrote the wheel. With a COM model, if I need an HTML renderer or an XML parser, I can get one. It shouldn't matter what language the component is in, I should just be able to use it.
Now, back to your first argument. Yes, the Microsoft implementation of COM might not be the best. And their components might be buggy and bloated. But we're talking open source here. Those components can be rewritten and fixed. The COM infrastructure can be debugged until it's perfect. You might as well say that C++ sucks as a langauge because Visual C++ is a shitty compiler. The two have nothing in common.
``Miguel also should have picked a better title. "Unix sucks" is *not* going to get the mainstream to read the article, they're too used to one-line sound bytes''
``Unix Sucks'' was not the title! The title was ``Let's make UNIX Not Suck''. I don't think there really could have been a better title.
--
Ski-U-Mah!
Um... you're not serious, are you? Corporate Dictated Evil is a rather bad enviornment for me. Perhaps it works for you, but I have run into many problems with it, mostly with ToolTalk issues. Besides that, I find it a rather clunky and unpleasing interface, overall. It's not _terrible_, really, all in all. But it's far from what I would consider good.
But that's what's nice about UNIX... we have diversity. If it works for you, great. Have at it. It doesn't work for me, though.
Code Reuse was the mantra in the eighties, not the Next Big Thing for the year 2000. There are obviously some cases where it makes sense, but its not a cure-all for derailed software projects. Code reuse is well suited to projects with a short development cycle, a short life cycle, and a small user base. Most internal IT applications fall in this category. But it doesn't make much sense for projects with ongoing, constant development, long life cycles, and millions of users. This is where fine-tuning "custom" code makes sense, despite the current aversion to hand-written code by people who consider themselves to be knowledgeable about such things. Every re-write is an opportunity to improve the code. Software reuse effectively eliminates this opportunity, and in time leads to an obsolete and brittle code base. Code reuse is a part of effective software development, but it shouldn't be the central tenant around which it revolves. That distinction belongs to good design and well-written code.
The 'no policy' policy of X is a Good Thing, in my opinion. There are some advantages to having a consistent UI, but they are outweighed by the disadvantages. A certain amount of chaos always accompanies innovation, but chaos is better than being subjugated to an inflexible policy. There are always going to be people who want to force their ways of doing things upon others, and UI policies are a great way for them to accomplish this. The best policies are the ones that are voluntarily adopted by large numbers of users over time. If it works for that many people, then there's probably something good about it. But if there isn't consensus in a particular area, trying to enforce policy is not going to meet with much success. MSFT gets away with this because they have a more or less captive user base.
Miguel has a few good points here, but overall this article could be more appropriately titled "Let's make UNIX suck like Windows".
Well, hang on. Is that the fault of UNIX? Or is it the fault of the developers? I mean, there's no reason why you can't write some code that take some arguments and gives you back a Motif (or whatever) widget that anyone could use. I've done it for small stuff like drop-down menus, but it should be possible to scale up. It takes some thinking sometimes, but doesn't everything? :) The operating system is separate from the interface (something MS and Apple never figured out). I don't think you can blast the OS for the problems in the interface.
As Far as html editors(aka homesite) go, try bluefish.
>And I thought the /. bias wasn't that bad..
You speak of Slashdot as a single entity. That is absurd. At best, it is a gathering of relatively like-minded people.
Most of these people are of like mind because they support Linux, a BSD, or something like BeOS. Others could care less. However, perhaps the most unifying aspect of slashdot's disparate readership is an anti-MS bent.
You may call this "bias" if you wish, but it is more of a shared belief. Slashdot was never "unbiased". It started out as Rob's homepage. He would post links to things he found interesting. People with similar tastes starting frequenting the site because *they* thought the links were interesting too. The Slashdot "community" grew in this self-selecting fashion.
Miguel is effectively reimplementing Windows in open source. Slashdot has provided a home for many who dislike Windows. Why would you expect the readership to react with anything other than distaste?
> Component architectures are vital to a good GUI, code reuse is key.
Says your CS professor. I don't agree. You're use of the word "good" is revealing. This is all very subjective.
--Lenny
As soon as you standardize enough stuff like that, you end up with one system with one set of programs, and then *gasp* you're no better than those other proprietary systems. UNIX has a beauty in the way it is.
How does it affect the overall power of the system to have one command do the same thing in every app on the system? How does it affect the overall power of the system to make that command a default standard for all systems? MOST people are used to crtl-c being "cut". Make that a standard. Now, when I sit down at a system I can rely on ctrl-c implenmenting a "cut" function. My productivity increases because I don't have to figure out a new command syntax on every app on every system I might work on. "But.." you say, "I was ctrl-c to be copy, and ctrl-s to be cut, because 's' makes me think of scissors." OK, no one is saying that they will take out your ability to change the default, just that it might be a bit easier to have a default (a universal default) to deviate from. If you want to change all of your personal systems so that ctrl-alt-shift-3 is "cut", that's fine. Even then, if you tell me that ctrl-alt-shift-3 is "cut" on your system, at least I can count on that working throughout your system. Now if you want to cofigure you systems so that a diffent combination of keys causes "cut" on every piece of software on your machine... Well, that seems pretty silly to me. The "cut" example is obviuosly over simplified, but I think that is possible to come up with a set of default standards that "power users" can then deviate from if they choose.
I'm thinking of taking as much original UNIX source as I can find, maybe even taking the kernel source out of the Lions book, and writing a new UNIX system - sans graphical interface. Pure and simple command-line bliss. You get yer sh, csh, ksh, vi, troff, lpr, etc. to work with. That sounds like a system I could handle.
Have fun! I rather like graphics. I do most of my adminstration from the command line, but games, the web, and even word processing would really suffer.
I don't need a million points of light, just two points of multi-mode fiber and a 10 Gig-E router.
>We have reduced all the complexity that you have described above now. To install, setup and configure your whole system:
>lynx -source go-gnome.com | sh
Funny, that didn't work too well on my Slack 7 system.
Perhaps you Helix guys can fix this?
I'd like to actually try your software sometime, but I really don't have the
time to compile a zillion GNOME libs...
(And no, switching distros is out of the question.)
--K
...Then again, maybe I should just ask 'Bob'...
=-=-=
Modern UNIX varients aren't really what it was when it was invented... thats okay. Things change and they do evolve. People in the tech field should be the least shocked by change, but I tend to find its usually the opposite. Standards are a fine and great thing but expecting a standard to last forever is naive at best.
F /...
Just remember the original mantra of UNIX was along the lines of "do one thing and do it well" very few modern unix apps or utilities adhere to that.
---
Solaris/FreeBSD/Openstep/NeXTSTEP/Linux/ultrix/OS
--- I do not moderate.
More stuff just crossed my mind:
Miguel brings up "Samba, Apache, NFSD, innd, sendmail, in.named, ftpd and ssh" as example of programs that have little or no code reuse outside of libc. He mentions Internet Explorer as a great example of an application that has reusable components.
Which applications are stable and efficient, and which one is a bloated beast?
Used to be, anyway. But there's no way I'm installed eighty-eleven libraries the hard way. I'm gonna find RPMs. And RPM -U removes the old lib. Whoops.
That is a misfeature of RPM then (and other packaging systems which have the same problem). Dependencies should not be an either/or thing -- different versions of libraries can and do coexist just fine. I agree that -U should not nuke old libraries by default, but an alternative would be --install --force, whereby both library packages are in place. Of course, one must use this with caution, as many packages include other files (headers, config files, etc.) with libraries, whcih IMHO is also a mistake. Libraries are LIBRARIES, header files and config files are something else. The -devel scheme tries to address this and (mostly) succeeds, but a more explicit approach might be better:
package-0.0-1.bin.rpm
package-0.0-1.conf.rpm
package-0.0-1.lib.rpm
package-0.0-1.devel.rpm
Whatever scheme is used, I agree it is a mistake (and disengenuous to some degree) for popular packaging systems to actually undue one of *nixes tremendous strengths: library versioning and peaceful coexistence.
The Future of Human Evolution: Autonomy
My guess would be that much of this has to do with code reuse in graphical applications. Netscape takes up a lot of space, but not one byte can be used by other applications. In contrast, MS apps can make use of the code in IE (even the web browser part of Winamp).
The same could be said for StarOffice, which is a big bloated mess, but can't share its code.
The real future of Linux is looking towards things like Mozilla and galeon, where galeon can reuse the code from Mozilla to create a small browser.
-- Ever notice that fast-burning fuse looks exactly the same as slow-burning fuse? I didn't... (Edgar Montrose)
You can implement just about any programming paradigm you like in just about any decent language you like. I could implement features that make BASIC look like Eiffel, but the problem is that it's just coding convention. To cliche, "actual mileage may vary".
Along the same lines, the question isn't "can UNIX be a modular component-based system", or even "is UNIX a modular component-based system", but rather "is UNIX being used as a modular component-based system". Looking at the current state of affairs, I'd have to say no.
The exciting thing, though, is that I'd have to say yes! to the previous two(okay, the second has a little free-play in it), and that's what I think Miguel's trying to say. The tools are there, but not enough people are using them.
This is a manual virus. Copy it to your sig and help me spread!
The primary difference, in my eyes, is that with open source, there's a chance of breaking this cycle. If people can be persuaded to support a larger project, or combine efforts when their applications are similar in purpose, then they can learn from each other's mistakes, and come up with a much better product. And, the little projects that fork off from the "core" codebase sometimes evolve into something that's better suited to a particular niche.
Would a tool like thttpd still exist if it had been written exculsively for Windows, and the source had been closed? Sure, Microsoft might have simply bought the rights to it, if users wanted that functionality, and rolled it into the IIS codebase. But then it would just be another checkbox on the same monolithic monster, instead of a tiny, hella-fast "ace in the hole" for certain applications.
I would hardly say that Windows programmers don't "recycle shit that's already written," since they largely put together their projects out of Microsoft-supplied code. The Windows platform basically forces you to use the "blessed" libraries. That may help to limit duplication of effort, but it also limits your choices.
>Right now, Linux is too complex.
Uh? Just like a pilot who complains about too many
controls on the dashboard.
Again, too complex compared to what? Coffe maker?
Dammit, it's an OS, hi-tech product. Niether OS
is simple. Windows is complex. It can be made
fast and stable (2 bluescreens on NT4 in 3.5 years here)
but it requires _dedication_ and _knowledge_.
If you want something simple, seek
elsewhere.
KuroiNeko
Your examples of software projects that fail to have code reuse are mostly (or all, I'm not sure) propriatary non-free projects?!?
I've seen studies on the amount of code reuse among free software projects, and it's quite surprising how much is reused. For libraries you don't mention like readline and regex to small bits and pieces here and there.
"The only common denominator on those applications is libc and Xlib."
Perhaps you aren't aware of a little program called `ldd`. Try this:
ldd /usr/bin/* 2>/dev/null |grep "=>"|sort |tee /tmp/ldd.1 |cut -f 1 -d " "| uniq > /tmp/ldd.2; for i in `cat /tmp/ldd.2` ; do echo -n "$i : "; grep -c "$i" /tmp/ldd.1 ; done
That's what my "computing experience" is about, and it's not something I would ever want to try with a drag and drop interface.
I've got no problems with there being a graphics library (ala GGI, maybe something with GL in it?) but I prefer to use a CLI for most everything... granted there are some things that graphics is nice for (like graphics apps) but in general I have need for only CLI stuff.
Free BeOS, runs from a Linux partition
The article is really good, but I think that he falls into the same trap as everyone else. What do I mean by that? He is creating another system to do componet level reuse when they should instead be focusing on a unifying policy. There are no less then four different object models at this point (Mozilla's XPCOM, Gnome's Bonobo, KDE's whatever their new name of the day is, and gnustep's ib).
/proc filesystem called /options. If you want to change something, cat a new value into it. If you want to find out what something is set to, read the file. Include interpreters to map sendmail options into the tree (something like /options/senmail/rulesets/6) and someway to store that either by a translator or in XML.
/World/Home. Options could be mapped into /World/Preferences/User or /World/Preferences/System). Persistantly write objects into somekind of back store by their Corba id or XPCOM id in /World/Objects/serialize/global or /World/Objects/serialize/local.
/usr/local/perl5
n t");
Instead they should be looking at a unified policy. The reason that Linux will never rule the desktop the way things are is because Microsoft is simple. You want to change a setting for the system? Goto the control panels. Change a setting for a application goto options->preferences.
I am not saying that these are the options to use, but instead imagine the following. Envision something like the
Better yet, do it in RDF and let any arbitrary program write to the RDF tree like a filesystem. For example, a translator could map the filesystem into something like
Use translators to set options for apache etc. Use mozilla or IExploder to set your configuration. You can probibly serialize objects into the RDF tree and bingo, you have poor-man's DCOM and object sharing. Wouldn't it be cool if you could write something like this in perl
#!
use UnifiedModel::RDF
my $print = new RDFNode("/world/www.ahost.com/objects/default_pri
$print->isA("Printer") || die 'Could not Open\n';
$print->print($text);
Why should we do this? By having a loose policy implemented via RDF or something, we have a single simple policy for storing information and a powerfull way to share componets.
I am seriously considering coding something like this. Anyone else interested?
Is it really true that to get shared graphical object code we also have to get crap desktops, applications that duplicate (badly) the functionality of plain-X based or Windows applications, huge downloads, and interminable pundits with over-developed messiah complexes.
LISTEN UP: Linux needs a decent, small, modern file manager (at least as good as the old neodesk for the Atari) and that's it as far as OS-level improvements. Shut up about your tedious Windows-clones. Get some apps out.
We have WindowMaker, so there's no point in churning out huge, bloated, slow, memory hogs like KDE/Gnome.
I'm very annoyed now, so I'm going to lie down.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
In the Windows world, you can (almost) always embed any document in any application
Ya,..
and monkeys might fly outa my butt
Dirty Pirate Hooker
Well, I noticed the previous poster made a comment that one of the first rules of hacking is to not reinvent the wheel. I also noticed that Miguel de Icaza was going on about the importance of Code Reuse. But it hit me: isn't this exactly what Helix has done? From the description, it sounds to me like all the Helixcode installer does is already present in the Debian package management system (which I'd like to see spread to every OS on the planet, including Windows, but that's improbable.)
(currently testing something about signatures here)
"Whatever scheme is used, I agree it is a mistake (and disengenuous to some degree) for popular packaging systems to actually undue one of *nixes tremendous strengths: library versioning and peaceful coexistence."
What worse, both problems ("GNOME needs a lot of libraries" and "RPM doesn't do library upgrades well") come from one company. I've never before been on the "RedHat Sux" bandwagon, but I'm starting to agree with them. I've always said that someday I'm moving to Debian. Maybe I'll make that a weekend project some time soon...
--
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
>3. Mail Client.
>Sorry, but you've got no defense here. Balsa, Mutt, even emacs will read mail. Gnome folks are even building an Outlook clone.
>4. Editor. Uhh, I use vi and emacs when there is absolutely, positively, nothing else available. Don't get me wrong, I first learned emacs over 8 years ago. But there are some basic functions which I rely upon that don't exist in emacs. Give me something like HomeSite on a linux box and you've got a convert.
Try Screem.
That's whatI liked about the redhat distro. It came with Pico and pine. 2 great tastes that taste great together. If Corel Linux was made for the native win95 users for its fancy interface, why was pico and pine left out? Those to me are the easiest to use console mail/editor apps that I have used since 1993.
Just my 2 cents.
alternatively, you take the next Linux distro that comes along and you have it all... Want to have a shameless plug? OK, than you will have it .-)
All of the Helix Gnome 1.2 has been integrated in Linux-Mandrake "cooker" (i.e. experimental) distro, and will be in shops in a few months. In a meantime, one can use "urpmi" or its X counterpart "RpmDrake" to get all you need installed in one step.
I am quite sure that debian users enjoy about the same level of easines with their "apt-get" and co., so things are far less problematic than you think.
> especially if you don't want to use the
> (admittedly slightly better) Xemacs (don't want
> the bloat, don't like X, want to be able to edit
> w/o X, etc.)
XEmacs does not require X11. In fact, it supports more features in a terminal than GNU Emacs does (font lock, etc.). Maybe you ought to try it again?
(Actually, XEmacs drives me nuts; I only use GNU Emacs. But I just thought you should know.)
No, learning to code is not copying people's work. If you want to learn to code, then use parts. peices. Toy with it. But dont make an entire copy of some fucking way overdone app and post it on freshmeat and consider yourself a baddass open source hacker.
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, 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.
At least then they are contributing something... How many of us in the "community" (myself included) have contributed anything?
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.
DNA just wants to be free...
Well, the "integration" of Linux Mandrake of Helix GNOME is really sad. There is no single day that passes without Jacob receiving mail for the broken way Mandrake distributed Helix GNOME.
Miguel
UNIX was created to deliever useful computer access to the desktop. That meant teletypes and their kin, and early CRT terminals. Slow, text mode - you didn't want to type much nor get much text back. How many /.ers remember when a good percentage of UNIX commands just returned ' ? ' for an error message? Great if you were familiar with the command and simply had mistyped something.
The OS is not the user interface. A good OS works with a number of models of user interface. A good OS does have functions and libraries to help with common operations; a good OS might set standards on how a program should handle reconfiguring (ie - not support but guidlines or rules). Just becasue MS has smooshed the layers together to make Windows, then split them apart in a different fashion but not drawn a lot of attention to this, does mean that other OSes have to abandon good partitioning.
That's because the libraries are all still under development. If glibc was still in the process of being written, and you downloaded a program that called a function that was added just last week, you would be in the same situation.
Give the infrastructure some more time to stabilize.
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
The ability to evolve and survive is indeed one of the strongest features of and *NIX system, but there comes a time where rigid standards and enfored policies in the forground are necessary.
For instance OpenGroup has required CDE as part of a distribution in order for it to be called UNIX. Although I personally do not like CDE, the use of a standardized window manager that allows for multiple flavors of UNIX to look and feel similar is a necessity for its survival. It allows for application developers to hit a target that is not moving, they may have to deal with some library issues but they don't have to deal with customizing the UI to several different standards too.
At the same time we do need to keep the flexability that *NIX enjoys. That is one of the reasons why I switched to Linux. But I have quite a few friends who want to switch to Linux and just want a standard GUI. They don't want to deal with which window manager, which application manager, etc... They have enough problems deciding what distro to pick. They don't want to take sides in the geek religious wars that are being waged, they just want it to work and consistantly.
Linux needs more standards, especially in the GUI arena. I say keep the religious wars in the background, but allow them to be accessable to those who want to participate. Decide on standards and then send them to the forefront. This will make companies trying to support Linux happier, it will allow for easier customer support, and will draw in a larger group of users.
Disclamer - Opinion of Person
Are you making fun of my LEAN TO??!?!
mov ax, 13h
int 10h
I'm so used to mentally adjusting for bad spelling, that I unconciously saw desperate user base. I had to reread to decide that it was actually spelled correctly. :)
ambiguity ain't it great
Paco is an employee of Tovaris, Inc. who speaks his own mind and not theirs.
The biggest source of flexibility in UNIX is that everything can be manipulated with linguistic tools. If Microsoft ever ships a truly easy to use from-the-command-line scripting system that can easily interact with and manipulate COM objects, they'll have achieved much of the flexibility of UNIX. If they ship Perl/Python, then they'll have a language rich enough to generate its own hashtables and lists of data that can then be analyzed/treated as if it were a text file, and regexp's and the like will be available to work with their full COM suite.
I've spent almost five years now developing a GUI, object-based sysadmin project for UNIX, and it has taken almost that much time to convince some die-hard UNIX traditionalists here that the very poweful consistency safeguards, error checking, privilege delegation and support for n-user simultaneous editing that it provides was worth giving up the ability to do grep on the passwd file.
I'm with Miguel all the way on this.. something like COM can mean *more* flexibility, as long as we have good scripting tools that make working at the higher level easy, and as long as the COM-style interfaces are designed with a *lot* of thought towards flexibility and security.
If we get COM-style interfaces that prevent us from doing things that the designer thinks we shouldn't do (such as setting a pre-hashed password for a user account, which NT doesn't provide an API for), then a COM would become a barrier. If the interfaces are designed to be as open as possible while still hiding implementation -specific details and providing safety and error checking, then a COM becomes a tremedous strength.
I sure wish Miguel would have talked some about security, though.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
Back when I was a total computer newbie, I was using a DOS computer. I knew nothing about DOS, but I had a program that would dial up to BBSes for me. My roommate set that program up, and I used it. After a few months, I got a shell account on an ISP. I knew nothing about the 'net or UNIX. This ISP had a great menu system, though. It would give me options for commonly used programs and system functions, and while it was doing that, it would print out the exact command that it did. After a while, I started using those commands directly at the system prompt, to save time.
Soon I was looking up man pages on various commands like vi, as I tired of the limits of pico. I was looking up various things on how to customize my shell and use it better. A little while after that I was installing Linux on my home system (this was a few months before kernel 1.0), and a couple months after I managed to get that working with X and PPP, I wiped out my DOS partition. I've been learning much more since.
I don't think I would have started out liking UNIX at all, if I didn't have some sort of guide like that character based menu, that told me exactly what was happening behind the scenes in the shell.
Something of this concept, perhaps in a GUI even, would be very good for beginners, and would do nothing to cripple things for advanced users.
Did you read the talk?
The section "Unix Components: Small is Beautiful" addresses the Unix component model you describe, and its deficiencies.
-David
Yes I want. Let's say I have a nice-looking little spreadsheet containing graphics and experimental data. I like to be able to embed it in the main report. That way I can produce special content by using unrelated applicationx and bind the result in a main document. Only a Linux zealot would agree that such a feature is crap.
With unix, you have to export the content as an encapsulated postscript file and, if supported, embed it an application. Now If I want to modify the embedded document, I need to re-export it and reload it. That works if the app support that feature but most of the time in the Unix world, this is not the case. In the Windows world, you can (almost) always embed any document in any application. Try to do that with unix.
It has often been argued that competition is good, and therefore we need both KDE and Gnome. But after reading Miguels very nice article it seems to me that this is not the case. The thing we really need is common standarts. If KDE and Gnome are not willing to make a common standart then it might be time for one of them to die.
I'm all for making things easy to learn. I am NOT in favor of making them just like Microsoft.
I totally agree that GNOME, KDE, Linux, and Posix based systems should try to avoid being like Microsoft (with the execption of COM / CORBA type stuff). Actually, I would say that user interface developers should say "Microsoft did it this way, that means it must be bad, unless there is real academic research backing this idea up." (real academic research means research not being preformed by the Microsoft did it all right morons who sometimes get tenure in CS departments.
Unfortunatly, I do not see how the complexity you describe relates to that (execpt the associate files of this type complaint). I do not think I'm the only one since all your other replies go to answering the library question without answering the associate file question or the larger question of copying Microsoft. This means you really need to express yurself more clearly.
Anyway, I agree with you, that there are many stupid things which GNOME (and KDE) get from Microsoft. They shuld really try to emulate a good user interface like Plan9.
The Christian religion has been and still is the principal enemy of moral progress in the world. -- Bertrand Russell
or those running slackware? same story
finkployd
From what I have been told by people who have used Posix on NT 4.0 there is one "thread" in NT that deals with the Posix commands. If if crashes NT is fine but if you want to use Posix you have to reboot. I personally haven't used the posix capabilities within NT so I am just going off of what I have been told.
Disclamer - Opinion of Person
Some very good points here. When I get moderation I'll remember to come back here and bring this up.
However, I'm not convinced that XML should be used. I would insist that the configuration file abstraction be one layer up, meaning any configuration format is allowed as long as the common parser can parse it into whatever the tree might look like in memory. Then your at the same point you would be if the file where xml. IOW the memory model is the same but persistent storage is cofigurable.
I have looked at XML quite a bit. I haven't written code for it, but think about what a typical config would look like in XML. Try something as trivial as syslog and you'll see how ugly it can get. Not all configs look like they map into XML as well as apache.conf or smb.conf.
KidSock
Making things simple is difficult; that's why most solutions will not be simple. However, there is a big difference between simple and stupid or dumb. Moreover, stupid and dumb may usually describe non-simple overly complex solutions. Too many controls on the dash board (i.e. screen) is not appropriate for OS because its counter intuitive. This does not mean that controls should not exist; controls should exist and be presented in a smart intuitive way. If you HAVE TO revert to the command line instead of HAVE THE OPTION TO revert to it then your OS will probably is not intuitive and will not be successfully absorbed.
See my response to miguel
You are one confused person.
:-)
It is based on COM or whatever name they give to COM these days (COM+
miguel.
Double click the installation file.
Run the program.
I guess that is a bit tough for some people...
It is when this doesn't work; or Windows informs you that in order to do this, you need the latest updates to X, Y, and Z; or it overwrites a DLL needed by another program; or it trashes your registry; or it puts stuff all over the system that doesn't get removed by the uninstaller, or ...
Okay, I meant "finds a place for them" as in "installs them in a location appropriate to your distribution". Sorry if I was being unclear.
Erm, familiar with rpm -i? It keeps the old lib installed.
Sheesh.
Or maybe you can go to their web page and look. They also provide .deb's, .rpm's, .srpm's and .tar.gz's if you want to compile it on your own. The helix installer is just a frontend to whatever package manager you happen to have installed on your *nix flavor of choice.
But hey, what do I know. I took the blue pill.
---
--
If I actually could spell I'd have spelled it right in the first place.
That was a very, very good article by Miguel. Unfortunately the first few posts I have read are from posters who obviously didn't read it and instead are making personal attacks at Miguel.
Huh. I saw Miguel deliver the talk in person and I spoke with him afterward. He seemed quite uninterested in hearing anything about the large number of small, irritating little things about Gnome that suck. The problem with Miguel is that he's quite unwilling to admit that Gnome *does* suck in many small, irritating little ways that could be easily fixed. Until the guy at the top understands that his project is going to *continue* to suck in many small, irritating little ways, well, hmm, it's going to continue to suck in many small, irritating little ways. What part of this is hard to understand?
--
When all you have is a hammer, every problem starts to look like a thumb.
Yup. But if you choose not to use the helix-code installer, you're "screwed" in the same sense as a guy who decides he doesn't want to use a hammer for pounding in nails. It's your own fault, buddy.
The GNOME project was started because of the licensing problems in KDE and Qt: the result was not a free system
Miguel
We have reduced all the complexity that you have described above now. To install, setup and configure your whole system:
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.
That said, Miguel has a point about code reuse, and my guess is that many people reinvent the wheel because they enjoy the challenge of coding. We certainly are on the way to reuse with things like Bonobo, and I think we'll see more reuse in major projects than we have in the past because it makes architectural sense.
Miguel also should have picked a better title. "Unix sucks" is *not* going to get the mainstream to read the article, they're too used to one-line sound bytes.
Q:Doctor, how many autopsies have you performed on dead people?
A:All my autopsies have been performed on dead peop
As for the GNOME needing lots of libraries thing... don't blame Red Hat... heck, I wouldn't even blame GNOME; if you're trying to make a component-based structure for building applications, such is the nature of the beast. Not that you shouldn't move to Debian... but don't give Red Hat (or GNOME) such a short shrift.
Additionally, all of these wonderful libraries create dependency problems
This is mostly because it is still under rapid development, and is somewhat bleeding edge.
You argue that it's bloated, but again, take a look at Star Office, Netscape, etc. Now imagine trying to run 10 Star Offices concurrently. THe point is that facilitating code reuse leads to less "bloat", not more. Storing and loading 3 APIs that do the same thing is "bloated". Software reuse is not.
And the only way any of this stuff will define "policy" or encourage reuse is if Gnome is the 100% development standard, something I think is unrealistic.
Wrong. For example, if the KDE and GNOME people agree on policy, then that will encourage reuse. If you're a developer working with GNOME widgets that other people have written, that is also reuse.
An important aspect of reuse is that it greatly accelerates development time.
Yeah but it's not free (as in speech) and that is one of his requirements. It's one thing to pick a tool because it's a good one, that does almost what you think it should do. However, he has requirements that specify in stone what he requires, and sorry, but nothing exists that would fill them. Else, he wouldn't be creating a new one.
Blah, blah, I know what you going to say. "What about KDE?". Well that is linked to libraries (Qt) that aren't technically Free Software. I'm not worried about Qt pulling out, because of this agreement. Regardless of your opinion about which license suits your requirements, the BSD is not considered Free Software(Tm) and therefore again, would never meet his requirements.
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.
Free BeOS, runs from a Linux partition
What he is doing is configuring his computer so that it works the way he wants, and not the way that some developer think it ought to work. He is not limited to the list of options that some developer offers him (as you invariably are with any GUI); he is able to select from a virtually limitless set of configuration options.
This is not necessarily "tinkering;" Frequently it's necessary for actually getting work done. Developers can't know or guess all the ways that people might wish to use software. Configurability is an absolute necessity, and it is this that GUIs destroy (and no, I'm not talking about having your choice of 12,000 themes).
Miguel says that Unix won't be around in 10 years. How many times have we heard that mantra from other naysayers? The simple fact is that it is the ultimate flexibility of Unix that has allowed it to stand the test of time. This is something that no Microsoft trash can track. I'll listen to Miguel's complaints when he has designed an operating system that has lasted for 30 years. Until then, he's just a young grasshopper who doesn't understand the wisdom of the Masters. He's not one hand clapping; he's no hands clapping.
Miguel grunts about comparing the best features of A with the worst features of B: this is a valid criticism. Yet he goes on to do the very same when he complains about a lack of code reuse in various daemons. I'll agree with him that there could be some reuse with respect to error handling and the like, but come now: these are applications with very different responsibilities, after the Unix model of doing one thing and doing it well.
In short, I think that Miguel has Microsoft envy. I don't. I can't wait to finish my work for the day (customers haven't yet been liberated from Microsoft slavery) and get back to working on a real operating system that I set up to work the way that *I* think is best: not the way that Miguel thinks is best, nor even a way that is just one of a number of ways that Miguel provides.
That is real flexibility, and there is no way on this earth that I'll give it up. Let the clueless learn on Microsoft dreck. Linux doesn't need to "succeed"; it's a free operating system!
DFL
Never send a human to do a machine's job.
The fact that we replied to it now makes it a troll.
One future, two choices. Oppose them or let them destroy us.
Normal people (ie, non-zealots) call it X-Windows. It's a conciet from the popularity of Windows, but it's true.
The same reason people rarely say "GNU/Linux" - it's not that we don't love the GNU tools, but give me a break, it's Linux.
Coca-Cola would have an easier time trying to convince people to stop calling it "Coke". We like shorter, easier way to say things...
I'm an investigator. I followed a trail there.
Q.Tell me what the trail was.
Recursive: Adj. See Recursive.
The problem with *NIX is that there are a lot of programmers using it (that is also its major benefit). Every coder out there is incapable of accepting than someone's code is better than his (except in some little situations; e.g. they are too lazy to code it, don't know how)... and considering the number of applications that are not that difficult to program, we end up having a thousand of different mail clients.
I believe it is too much to ask people to unify identical projects... I find hard to believe that there aren't more popular alternatives to Gnome and KDE.
That is the problem of Linux, besides some standarized tools, everything else has about twenty different flavours.
I don't see how to get out of this, rather than scraping it all. And I mean all.
Mac OsX is very interesting for me. If everything there is configured by XML and they enforce GUI guidelines (I forgot that's Apple), we could have a real cool OS; if they don't make the command line inaccessible and developing is not frowned upon.
Perhaps even the rumoured new Amiga is the solution, as people can use it on top of another OSes; and maybe the brandname is so strong as to pull people to it if they do the marketing right.
That's why I fear that Linux is going to face a problem in the near-future, as choice is good, but too much of a good thing is always bad
I agree 100% with what you wrote. This is something that concerns me a great deal in general. If Microsoft has their way with .NET there will be no room for Linux. So what are the biggest elements with .NET?
t s/default_printer");
The ability to mix and match objects.
Fairly transparent object invocatation, and the ability to access your information anywhere.
What if we had some kind of system that stored everything in a browsable tree. Ie, any object could serialize itself to the tree, and anyone (provided they had access permisions) could access, store, read and run parts of the tree. Even more so, what if everyone could access their tree locally.
For example, In c++
umGeneric = new obj_from_tree("oft://objects.blah.com/World/objec
assert(obj_from_tree->isA("printer"));
printer->print(string);
Parts of the tree could be simple dictonaries (in java, or hash's in perl) that have configuration files etc.
Sorry, but wouldn't this be cool?
Anyone interested?
1. Use the Helix Gnome Installer and select which packages you want.
2. Use an ftp client to download all the packages and then just install them all. They'll resolve all the dependency issues for you.
3. Get a distribution that includes the Gnome libraries.
----
Celebrate the finer things in life
Ugh. Big big Ugh.
COM is terrible, and he wants to bring it to Unix. Welcome to the world of fragile applications and bloatware.
There are very few applications that benefit from the app inside an app model (Excel sheets inside your your Word app). Few enough that those can be special cases. Why do you want to load a brand new DLL (shared object library) everytime a button shows on a form.
He mentions that a common criticism of IE is that it is bloated and unstable. Then he promptly ignores those criticisms and tells you how it's great that IE is made of a bunch of separate components. Sounds like the first propaganda chapter of all those ATL/COM/DCOM/COM+/MFC COM books. It's still bloated and unstable. Being separate components didn't solve that problem.
Most applications know in advance exactly what components they need. Why not propose/enforce a standard static library interface for GUI kits?
Ugh.
COM optimizes programmer time. VisualBasic and Delphi are very good at rapid prototyping. Arguing in favor of what's best for the average end user shouldn't really take this into account. You've saved yourself some time developing the app, but when some other app comes in and trashes your widget.so library with a newer version you've just hosed the user.
Oh well, at least I can avoid installing Gnome under Unix. I don't even have that choice with COM under Windows.
I could fit the things I know about Real Programming into a small thimble, but I'm thinking reference counting in this case isn't for memory management in the same way it is in language-specific OOP, but for tracking the use of distributed components.
:)
Instead of memory management, think resource management. First, the memory for an object has to be allocated somewhere, and the object itself might allocate some heap, or open files or sockets, etc, etc. Those things need to be cleaned up at some point, but you don't want to do it until the app is done with the object. But with refernce counting (so the argument goes) that's hard to do. If you can't tell if an object is not is use, you can't kill it/call it's destructor/free it/whatever the hell you call it.
I am a programmer (at least that's what they pay me for <g>), but I don't know anything about CORBA/COM/etc, so take my comment with a grain of salt the size of a brick.
Part of the problem is that there is no "Unix", in a concrete sense. Unix is more of a Platonic ideal than a specific system. Solaris is a kind of Unix, HP-UX is a kind of Unix, Irix is a kind of Unix, Linux is a kind of Unix (OK, maybe not legally, but philosophically), but none of them is Unix. To say "Unix does foo" is misleading; Unix doesn't do anything - specific implementations do things.
Miguel uses examples like ssh, Samba, and Apache. Are those "Unix"? To my way of thinking, no; they're applications written for implementations of Unix. Bad applications do not make a bad OS - you can write a Windows application that doesn't use any reusable code and breaks every standard, but that doesn't change the strengths or weaknesses of Windows. Now, Miguel is right when he says (or implies, at least) that certain systems make it easy to write component-izable stuff, and Unix isn't one of them. But I think he's wrong in implying that a monolithic component architecture is the answer.
Unix applications don't use reusable code or talk to each other? Sure they do - and I'm not talking about pipes, either. Does your web browser care what network card you have? No, because it only talks to the layer of the stack directly below it, and each layer of the stack is a black box only providing a fixed set of services.
Part of the problem with Unix GUIs, I think, is that they've broken with the stack-oriented model to some degree. The application is responsible for too much, which is part of why X apps tend to look very different. Sure, you can link to Motif without worrying about Motif's internals, but that only exemplifies the problem - imagine if your web browser was "linked" to a specific network protocol!
I guess I'm partly agreeing with Miguel here, in that you should be able to code without worrying about how services are provided. The difference is that Miguel seems to think that centralization is the way to go, whereas I think that decentralization with proper understanding of responsibilities is the way to go. It looks to me like in Miguel's world, you'd be stuck with one model for everything, whereas in a protocol-layer world, you can change any layer without affecting others.
While I agree that it would be nice to have the storage format of the configuration file configurable, I would schedule that feature for the second major release. There's a lot to be said for keeping the first version of an application functional but otherwise as simple as possible.
Later, it would be possible to add autodectection of a number of formats. A good example of the beauty of such a setup is UW's c-client mailbox interface, which transparently detects a number of diverse mailbox formats...
Hey, I am not a coder, just an end user and learned the hard way to just hate windows machines from experience and Linux is a godsent to me. I don't think I'll like a more "user friendly" machine if that implies dumbing down Linux! He writes: "Unix is a complex system internally despite its simplicity in its design, but it is not a system ready for end users. And this is what the GNOME project is building on top of the existing Unix foundation." Well, I for one am an end user, and like it the way it it, thank you very much! Let's hope this does not degenerate into another dumb box type operating system. Just my rant.
~~~Please pass the salt, I hate unsalted MD5s
True. It sno big harm. They just annoy me.
And my patience is thin. I need to get laid.
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+.
Is it so strange that the GNOME team primarily write GNOME components? GTK+ is a small and fast widget set and I think huge complex components like the GNOME canvas is the last thing it needs.
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.
AFAIK the only "GNOME html component" around is the GtkHTML component (used for example in the Helix Code Installer, Updater and some wizards). I'm pretty sure it works in GTK+ only apps too.
What you describe is similar to what the OODS team is trying to put together. Their idea is to have a single API for interacting with any kind of data held in a directory-style structure, with the OODS software providing client access, permissions controls, and back-end data store drivers.
They are just at the point of planning and discussing everything.. it's not clear that any signficant amount of code will be written in the foreseeable future, but if you want to join a discussion with people who are working on this sort of thing, check it out.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
wmx
It's great, I usually run about 10 virtual screens and it doesn't use up any screen real-estate on any of them. My Netscape window is sized right up to 1024X768, and wmx doesn't take any of it for junk it decides I need.
Just the thing for running a 16 copies of gvim (Graphical VI iMproved, for those who don't know), 10 xterms and having a half-dozen Netscape windows open on a 14" monitor (yeah, I'm a cheapskate, honestly I don't see much need for a bigger one with this setup). It is truly the ultimate development environment.
My one nitpick: I've got to get around to hacking on it a bit so when I start up a full-screen sized window, I don't have to manually center it so the tab is offscreen. Luckily, the source is small and quite hackable, so it should be fairly easy. I might also get rid of some of the shaped window stuff I'm sure is slowing it down a bit.
---
Despite rumors to the contrary, I am not a turnip.
The "*nix" thing ranks right there with the accursed "virii" plague in my book: it looks like a regexp to match all the Unices you mentioned, but it really isn't.
Oops, now we'll have the obligatory flamewar about "virii"...
--
Information wants to be beer, or something like that.
* My Background
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
What is your point ? If you want a web browser, download one. Mozilla doesn't depend on GNOME or KDE, neither does good old netscape. If you want to use a GNOME app you need GNOME. Kinda like how if you want to run a Win32 app, you need the Win32 library. If you want to run a Mac app ... yup, you need whatever libraries MacOS provides. Lets even jump back a step. Why do I have to install pthreads if I want to run mySQL ? Some programs have requirements, and some people decided that they are going to write a GNOME app. So, you can either download the libraries (I prefer them to come in several small libraries then in on 100+MB library) or you go off and write your own.
No one is forcing you to use GNOME or KDE or XFce, and some people genuinely like them.
I don't think Unix was ever built to have a pretty interface. After the iMac, it seems everyone wants to abandon functionality for style. Not that Unix is losing functionality by this, it's just taking away time that might have been well spent developing other features.
Some OS's weren't make to be pretty, and I think unix is one of them. I much rather have it's power then any other other operating system's GUI any day...
Help me through college please!
Some things people may not think of is that each computer user is his/her own admin at home - I would see many of the housemothers I help with their computers, how to fix things on their own etc, to scream when they realize they now have to type "find -print | grep filename" to find a file, when the poor WM has crashed and they do not know anything about how to fix lockfiles?. People may think many computer users are stupid, but some actually do try to help themselves out by learning about things - you really think Linux/*nix/BSD should be a OS just for tech-savy people like us?. If anyone would do a recode of *nix, or redesign and make it easy for people to use, configure, even when it has crashed and the GUI simply fails ?. People want a system where they can combine simple and technical - which I think MacOS X does a good attempt at?. Unix does not suck, but its simply too difficult for some people.
-Stskeeps, http://unrealircd.com
Or i would like to be able to add a document editing feature to my *compex* project. So all I need is waiting for October for StarOffice to bo GNOMEized.
Also galeon uses Gnome Transfer MAnager via ORBit.. Wow what a world. I just combine components and have a great application.
(Well i would also be able to add Terminal emilation to my bloated project via GnomeTerminal libs.)
I could fit the things I know about Real Programming into a small thimble, but I'm thinking reference counting in this case isn't for memory management in the same way it is in language-specific OOP, but for tracking the use of distributed components.
How else would one manage component lifecycle? Somebody clue me in, if only with an "Only a stupid luser wouldn't know that language blah has been doing it with blah much better way for years!"
"If you look 'round the table and can't tell who the sucker is, it's you." -- Quiz Show
Try "None of the Above" You don't HAVE to do a damn thing. That's one of the many beautiful features of GNU/Linux. Personally, I run Enlightenment as my Window Manager, and don't run GNOME or KDE... I tend to use all Gtk+ applications, if I can, but sometimes I run Motif, QT, TK, or other widget set based applications. I run the program that fits my need. Widget set be damned.
Semi valid point here, but Netscape 4.73 does function. It has it's quirks and flaws, but like you I normally have 5+ browser windows open constantly, and Netscape gets the job done...
Take a long hard look at CSCMail (http://www.cscmail.net) It will do all you need... And with a "One Stop" installation script, it seemlessly installs on MOST GNU/Linux and BSD distros....
I dunno... what do you need to do with an editor that gvim can't do for ya?
Star Office works just fine for these two...
Try getting a clue... that statement is just 100% false...You say:
Side note: I run GNU/Linux on my workstation (at work) where I link it to a corporate network with Novell servers, Windows 9x/2k workstations and Linux servers... I deal with inter-office mail (and its attendant Word and Excel attachments) just fine with my Linux box... I do not have a Win partition, I do not Dual boot, and I am 10x more productive then my co-workers. When they are all busy scanning their hard drives due to the most recent Windows macro virus scare, I am happily working. While they are re-booting their machines due to the most recent Explorer bug that brought down the whole box, I am happily working.
At home, I also run GNU/Linux (on my main box) I play Civ:CTP, Quake III Arena, Unreal Tournament, Starcraft, et al... I code, deal with e-mail, surf, everything anyone needs to do with a computer. No problem... I can do it all in Linux.
I DO have a Windows box... I use it for ONE purpose...
EVERQUEST!
But as soon as Anarchy Online comes out, I doubt I'll feel the need for that anymore, and I'll prolly end up wiping that machine and making it a GNU/Linux box too...
So, your arguements are pretty much baseless... You might want to take another look at GNU/Linux, and this time, with your eyes open...
Miguel
ESR says:
These are opposing viewpoints?! It looks to me like Miguel and ESR are on the same page.
---
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
I thought making UNIX look pretty was Apple's job... :P
--K
=-=-=
Funny, all I did was:e bian unstable main" >> /etc/apt/sources.list
echo "deb http://spidermonkey.helixcode.com/distributions/d
Maybe I'm missing your point, but aren't you, in fact, relying on Helix Code's installer to install Gnome? Helix Code != Gnome.
(Also, how exactly are they benefitting from giving the away this third-party installer that you don't really need anyway?)
Frankly, I don't have the slightest idea! But presumably the investors in Helix Code think there's some advantage. A company is a company, not a charity, regardless of how half-baked its business plan is. (You see the same thing with Napster -- it's a VC-funded business, not a selfless band of freedom-fighters, even if it has no source of revenue.)
Hari writes:
As long as the source for both pieces are released under the GPL, what is the problem?
Well, for one thing, there's little incentive for the Gnome project leaders to make installation easier when their for-profit side project depends on its being difficult. Beyond that, I agree that as long as their code is GPL'd, Helix Code and Eazel will never make a dime and that when they try to make money, someone else will simply walk off with their code. But, presumably they think they're getting some kind of lock-in. Otherwise, what's the point?
What I'm listening to now on Pandora...
Look at Mozilla XPCOM for this. They are not that far away. Replace the usual RPC mechanism with SOAP, and you have something a bit bloated (not nearly as bad as CORBA tho) but completly open, and understandable.
I would love to do something like this.
Well, I don't want to embed a spreadsheet in a document, but there are lots and lots of people who do. And I think the general concept is the right idea.
Just as it's cool that I can chain grep, sort, and uniq together in a pipeline and make them all work together to solve a problem for me, it will be cool to be able to get AbiWord and Gnumeric to work together to make a report. Business people have to make reports that show numbers and graphs, and then explain what they all mean. Why should they have to statically export the numbers and graphs and manually import them, every time the numbers change? Or would you prefer to turn Gnumeric into a general-purpose word processor?
Don't forget, when you embed numbers from Gnumeric in Abiword, those numbers can be cached. Then, you can work on your Abiword document without needing Gnumeric running at all times. Embedded data doesn't have to mean slowness and crashes.
As for bloat, which would be more bloated: components that can be shared, or duplication of features?
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
In the Windows world, you can (almost) always embed any document in any application.
I tried to embed an xl sheet into notepad. I just couldn't get it to work.... Once I received a word doc with a xl graph couldn't link to the data.
Try to do that with unix.
A long, long time ago(1990)... there was a system called NeXT. This was when the DOS dinosaurs romed the earth. (In reality I think it was when Win3 was out). I could drag, drop, embed, lipservice (voice e-mail), etc... Some features Windows is still missing today, ie. multithreaded, multitasking, stability. Guess what?... I still use it today. Still has more features than windowz. I'ts just sad that Apple bought them out and they no longer support Intel boxen. It would help if they finally get it out on PPC.
DRM? No thanks, I'll just get it somewhere else...
There are things to complain about in Emacs, but lack of features? You must not be looking hard enough. There are always at least 2 or 3 different implementations of any conceivable feature...
"I believe that the cult of the particular brings only death - for it bases order on likeness." St.-Exupery
Slackware.
Among other things he wants to enforce policy, for he complains loudly about the lack of policy enforcement in Unix.
Furthermore, he is already actively enforcing policy: I cannot use Gnumeric unless I install the whole of Gnome. Sorry, but that's one less Gnumeric user in the world (I'd like to give it a try, but not at the expense of all of Gnome. And no, I'm not a KDE user, either).
If he wasn't actively enforcing policy, then there would be configure options for turning off Gnome. Alternatively, Gnumeric would simply use those features for which library support is installed on the box. We get neither of these options from Miguel; instead we get policy enforcement.
Hello Microsoft.
DFL
Never send a human to do a machine's job.
I was agreeing with Miguel up until the point where he said that the interface of MS windows 95 was better than we had in X at the time. I disagreed strongly with that, for one major reason: We had the window manager. That means when a program dies, it doesn't freeze to your screen and eat up real-estate. You can still minimize it or move it out of the way. Windows *STILL* doesn't have this feature today. I get sick and tired of the way in windows a slow app that starts up "hourglasses" the cursor, eats up all the screen real-estate, and can't be dismissed until it wakes up enough to pay attention to my mouseclicks. Plus, the annoying focus policy of "focused windows must be on top" is really annoying to anyone who's experienced the luxury of typing into a shell window that's only partly exposed, while looking at the window on top of it (perhaps as a reference to what you are typing). The MS GUI has some big problems, and it scares me a bit that the maker of GNOME is someone who praises it and (apparently) wants to emulate it. Yes, the UNIX interface is old and crusty. But imitating Windows is not the way to fix it.
Don't label something "offtopic" unless you know the topic well enough to tell what's on topic.
Show me a usefull unix user application that is implemented with your so-called components and one-way communication pipes.
He's trying to turn our wonderful Unix-like systems into Windows.
I, for one, love the way applications are written now. He mentions how things like inetd and ssh have no code reuse. That's because they don't really do anything similar! libc does most of their work: socket(), connect(), select(), etc. There's no reason for these applications to share--and hence depend on--components.
Stay the fuck away from our Unix.
And that we've been hallucinating windows these last few years. Wise up and smell the components.
My Karma: ran over your Dogma
StrawberryFrog
I'm far from a Microsoft programming expert, but I think I'm correct in stating that although these interfaces have indeed remained static up to now, this is more due to a design flaw than by design.
;-)
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...
"The future's good and the present is nothing to sneeze at." - Roblimo's last
the problem is that it required a full install of Mozilla. I'm sure they created a nice browser interface, but for it to be truly complete, they need to throw out the Mozilla crap they don't need and create and distribute their own lib.
There are plenty of great projects that don't have excessive complexity. For example, I highly recommend the text editor e93.
It is really the individual application's responsibility to employ good form. Bad form by individual applactions is not the fault of unix.
for one... Unix and it's flavors dont suck.. they're fun in my opinion... second... windoze/macOS suck some serious shit... third, if anyone is gonna knock unix and it's variants need to take a crash course in unix admin. and be left locked in a room with a xterm with access to every man page on earth... 'nuf said now let me get back to rebuilding that damn kernel
One question, though... Are there many *n?x people out there who feel this is something we really need? Or is it just an accute case of code envy on the part of Miguel?
Information wants to be anthropomorphized.
UNIX is BUILT on highly modular components with a high level interface to glue them together. It's just that the components are command-line programs, and the glue is lines of text (records) through pipes.
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.
Secondly, I own 3 Loki games and am beta testing a fourth for Loki. That's as many as I own (recently) under Windows (I don't play a lot of games). How can you say there are no games?
Free BeOS, runs from a Linux partition
Right now, Linux is too complex. While Linux should certainly not imitate Windows, its UI(s) should be made intuitive, so that instead of forcing users to read through how-tos and man pages, they would be able to do what they need because the system would be intuitively clear to use. Command line UI, while popular amongst Unix users, is not simple. If you think otherwise, please print a script and let non-Unix people tell you what they think on that. While I do not think it should be abolished, something new must be invented, something that would have same or better strength but would be robust, intuitive and productive. Something that new users, non expert users can easily utilize as well as something that experts can utilize to the degree of their liking. When new Linux user, new to Unix or any other OS, will be able to start using Linux immediately, without reading a single How-To or man page, then Linux would be ready for world domination. Let's make it happen.
It would be foolish to think that the current abstractions we have deployed in Unix are sufficient and that they are good enough, and that we are doing just fine.
It's impossible to keep UNIX from sucking.
What makes UNIX suck for one person are the same reasons it doesn't suck for another person.
UNIX shouldn't try to be everything for everyone.
I just have issues seeing the problems.
If --force is needed on a non-development library package, the package has been created improperly (unless I'm wrong, rpm will overwrite symlinks without --force, and a library package should contain no non-symlink conflicts).
If this is a common issue, then a test for it should be added to either rpm itself, or the rpmlint test suite used by at least a few major distributions.
As for the difficulty of changing the semantecs... heck yes, it IS difficult, if it means forcing the current userbase to relearn and change their scripts.
First, the dark green of links is hard to distinguish from the black in some conditions. Then there's the black for the "clicked link", so after I popped it up earlier then closed it before reading it, the link effectively disappeared. Then there's the philosophy of putting the link to the talk/paper/article *anywhere* but the first time it appears as a noun. In this case, I had to scrub the text with my mouse until the end where the cursor finally changed over "read"
I swear, reading slashdot is like playing myst some days.
I've finally had it: until slashdot gets article moderation, I am not coming back.
I read your article and I think you're right on the mark about where we need to go. I just want that this doesn't become an open-source-close-mind project where only my carrots count. We NEED this kind of improvement on *nix to make it user friendly for the computer-literate-impaired, but we should be working together (i.e. not KDE vs. GNOME vs. whatever else)
So let's start cooperating and make Linux the best damn OS ever made!
LinuxTek
Signatures are supposed to be funny?
Hah, just the sort of West Undershirtian reply I'd expect. You are people too? Not from what I can tell. You sub-human visigoths are what give America a bad name abroad.
Go back to your single-wide, artificial stucco, outhouse-using life. You pig.
<SARCASM type=":)">
Potato chips are a by-yourself food.
This doesn't agree with my memory of how things happened.
Memory's a funny thing that way.
In 1987 Apple came out with Hypercard and its XCMDs (external commands) were the first component system that I saw widely used.
Sure
Honestly, I was pretty surprised to see how old the COM is. When I was digging around MS Research I found some old essays on components which dished out their interfaces (it was really abstract, the basic unknown interface wasn't called IUnknown [it was 'unknown' or something similar] but it was the very simplest form of MS's component model).
That same year Bill Gates wrote an interesting article in a special issue of Byte magazine saying that the software industry should make all applications "scriptable". Naturally he proposed Basic as the scripting language.
That nicety is built ON TOP of the COM, it's not provided BY the COM.
If I remember correctly, OLE was the major difference between Windows 3.0 and 3.1, which would place its introduction at around 1990. VisualBasic and the future COM followed soon after.
OLE is built on top of the COM. When OLE was released, the COM was already out.
This is off of my main point anyway, which is that it was conceived a long time ago, long before it was put into use. Programmers didn't really understand component programming for a while.
If you're really curious, check out
___
The ends are ape-chosen, only the means are man's. -- Aldous Huxley
Wish I could help you out, pal. I heard that Natalie Portman might be heading over your place tonight...
How do you pronounce Miguel's last name?
I've finally had it: until slashdot gets article moderation, I am not coming back.
They're reinventing the wheel. The standard UNIX desktop environment, CDE, already has all this. ToolTalk provides a much more lightweight and nonintrusive distributed heterogeneous systems component architecture. ToolTalk is part of CDE. CDE is an excellent architecture for a complete desktop, and is already the standard. If you look into the technology, you'll see this. So basically, either these guys are completely ignorant of CDE's significance and capabilities, or they know about it and they just want their name on something (NIH).
This is not a troll, this is an illustration of an opposing viewpoint.
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.
--
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
A lack of standards makes unix both good and bad. While infinatly extendable and configurable, you must relearn the conventions used by every different program. Use emacs, then try to use vi.
I heard little about Miguel prior to 3 years ago which leads me to believe that he has never really worked with too many UNIX systems.
/usr/src/linux
:)
Do me a favor. Go to a shell and try this:
$ cd
$ find . -name '*.[ch]' | xargs grep Miguel
Take a long hard look at what you see. Then think about your statement.
Perhaps you should let Miguel know about some of your concerns. You can easily reach him at miguel@kernel.org. Or miguel@gnu.org.
--
Ian Peters
Posix was a term generated by the government in order to get around some restrictions. Basically, when the government is trying to set standards for what they will purchase and not purchase they cannot use trademarked names, ie they cannot say "We want a system that is UNIX complient." because UNIX is trademarked. What they can say is "We want a system that follows certain guidelines descriped in the Posix standard." and then make the Posix standard restrictive enough to limit the scope of what they buy to UNIX.
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.
Disclamer - Opinion of Person
Er... no.
You've tried to find a gui for unix equivalent to Windows, which last time I checked doesn't exist, and when you failed you started ranting. If you want to keep using the Windows gui, stick to Windows. Really lots of people use it for businss and leisure, it certainly isn't that bad.
But let's look closer at your beef with unix, and why in my opinion it is totally irrelevant. Has it ever occured to you that the majority of people actually using unix on the desktop are happy with it, or they wouldn't be using it, and they'd probably hate being forced to use Windows, or anything else for that matter, because it would be totally unfamiliar to them just like unix was to you?
Has it ever occured to you that these users couldn't care less if there's a gui & set of apps functionaly & visually equivalent to Windows, since they don't *need/want* that functionality?
And before you step in and say that if more people are to start using unix on the desktop, such a gui must be created, has it ever occured to you that such people minght not give a damn if more people start using it or not?
Why should they care what other people use on their home box. I'm using someting that I know, like and am familiar with. If you don't like it, I honestly couldn't care less. I don't care what my users are using on our network either. They should be and are free to shoot their feet any way they please.
Lately I've been using windowmaker + wterms + gtk (gtkstep rocks!) w/ some gtk apps (gimp, gtksee, xchat...) and netscape etc. During the last year or so I seem to have stabilized on a consistent setup on my laptop, workstation at home & work etc., before that I would experiment often, try new things etc. Thing is, it's been almost a year since i last did a dramatic change on the setup appart from the odd upgrade here and there, the occasional tweak here and the odd background image change =P
I can say that I finally found the ideal gui for myself - i'm very productive, everything is in the right place, it's readable (contrary to 99% of the themes on theme.org). Granted this path to nirvana wasn't painless, but hey, there's no way an out of the box gui can please all people. Accepting anything prepackaged is bound to be a compromise, including windows.
Chances are, you're probably not gonna like my setup. My point is though, that I'm not gonna like your windows setup either. You miss some windows apps on unix, I'd miss some unix apps on windows.
Oh, and for the curious, here are some shots of my gui nirvana:
shot 1
shot 2
I didn't mean to mark that "funny," that was my mistake... I hope someone comes along soon and re-moderates it.
<O
( \
XGNOME vs. KDE: the game!
Will I retire or break 10K?
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
1^2=1; (-1)^2=1; 1^2=(-1)^2; 1=-1; 1=0.
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!
I totally agree with you
In the days of HTML and graphics app, Mutt is rediculous. I want to write HTML email with nice fonts and embed images. Try that with mutt. Outlook Express really kick the ass out of any mailer.
Just for clarification, could you specify what version of Windows you're speaking of? (For the record, when I say "Windows" in this comment, aside from the prior reference, I am refering to mainly Windows 2000, and possibly NT. Never Windows 95 or 98). NT and 2000, while not strictly multi-user in the UNIX sense of the phrase, do allow for multiple users and for a super user account (Administrator). Along with the super user account, NT and Windows 2000 have ACLs that have a much finer granularity than UNIX's standard permissions (yes, I know some unices have ACLs of a finer granularity than owner/group/world, read/write/execute. I'm ignoring those and many meaning "Linux" by my use of the word "UNIX").
/sbin becomes /.sbi, for example), and then links a more verbose name to those paths strictly for users (ie, /bin would become /.bi, and might be linked to /Applications). Makes it easy for internationalization), and an excellent help system.
That right there addresses numbers 2 and 3 in your "What's bad about Windows" list. As for number one, BSODs are typically caused by bad drivers, or bad third-party software (ie, stuff not under MS's control). I've had my own share of segfaults and such in various unices. This is not strictly a Windows problem. Granted, it seems empirically that Windows is more "unstable" than Linux, that's mainly due to the lower bar for entry -- Windows is easy to setup, but difficult to master. However, the "easy" part lures Joe Q. Randomuser, MCSE, to install NT. Of course, since he doesn't know what he's doing, and the system is too "easy" to require hiring an admin, he will generally fuck something up. Thus, the standard equation: stability = 90% administration, 10% hardware and OS.
Addressing number 4 in the list of "Bad" is simple -- Windows 2000 has a tab on the Task Manager to show all processes, with customizable columns. It can potentially show even more info than ps, and an "End Process" button is provided if you want to kill the processes. As well, the standard "Applications" tab still exists, but now it really only shows applications (as in, stuff with windows open).
For number 5, who said you have to write Win32 code? There are wrappers out there that make it nearly trivial to write windows code (sure, MFC is bloated, but there are other options). At the same time, win32 code is much cleaner and more sane than, for instance, X code. In my experience, writing win32 code is typically not much harder than writing gtk code, and (in my opinion) is more rewarding.
Anyway, I didn't reply to this to counter each "Bad" item you listed. On to other things.
I suggest you look into cLIeNUX (http://www.clienux.com) for a distribution of linux that is doing some very neat stuff for client users (what I assume you're wanting when you ask for a single-user version of unix). Aside from the fact that you're pretty much root, cLIeNUX has a new filesystem hierarchy (Dotted Standard Filesystem Hierarchy (DSFH), which "hides" directories using the dot notation (so
As for the problems with the GUI (X), the only sane solution is to get rid of it! Seriously, X is what's holding linux (and other unices) back, in the gui realm. Why is it that Windows and Mac OS tend to have applications with a consistent look&feel? It's because there aren't several hundred window managers (I'm not making that number up). There is one system that handles rendering, and though you can change shells with Windows, the widgets and such all look pretty much the same. Granted, the current designs for Windows, Mac OS, BeOS, etc don't allow for X's network transparency, but that wouldn't really be too hard to do (look at Terminal Server). What X needs is a standard widget set (none of this Xt, athena, motif, tk, gtk+, qt, etc crap), at the very least. on the widget level, you can enforce look&feel, and keyboard accelerators. Of course, that's never going to happen.
my > $0.02
I prefaced my comments with the disclaimer that I am not an expert on the Microsoft programming world - in fact I appear to know just enought to get me into trouble on occasion.
;)
Right, you prefaced your comments with disclaimers about your inexperience with Microsoft-OS programming and then you proceeded to comment on and belittle the system about which you knew very little. I hardly think that's fair (least of all that you should get moderated up for it!).
On the interfaces issue, it appears I was simply misinformed.
OK, but it's not as if Microsoft created this simple extensibility (see IFoo/IFoo2). You can see it all the time in growing structures.
As for the DLL issue, you are right that this *can* be worked around, but must be done at compile/link time and this is not normally done.
It can also be done at runtime or just before you run the program (depending on how the program is written). The system doesn't provide an elegant way of enforcing nice usage of dll's, however, which is one of the big reasons that MS has been pushing the COM.
If you're dealing with a vendor app and the vendor didn't take the care to ensure conflicts were avoided, you're out of luck.
(This is only in the context of simple procedural dll's)
Of course. If you get bad software then you're out of luck. This doesn't change on other platforms (bad software is on every platform) but Microsoft makes the dll problem a bit harder for bad software to exploit by using the COM.
As for who at Microsoft said this, it was several top Microsoft SEs working to evaluate the feasibility of switching a *very* large company's Unix shop over to NT
SEs? Does that mean 'programmers?' Why were they working on switching another company's systems over? Were they OS programmers?
Believe me, they wanted to say they could do it, but they couldn't - they all said it was possible in theory, but completely impractical and that they could not guarantee that the OS would "do the right thing" when running two different versions of the same app.
What?! These couldn't have been OS programmers. If the applications don't 'do the right thing' when running at the same time then it's the fault of the applications, not the OS. What version of Windows was this? If you are REALLY concerned about each application using its own version of a dll, put it in the same directory as the application (though this mostly ignores the purpose of dll's).
As for why you'd need to run two versions simultaneously - it's an absolute requirement in the real world where you want to validate the new code (especially for designing life-critical systems) alongside the proven code for a while to make sure the answers match.
OK, I'd originally thought that you meant debug/release versions of the exact same version of an application. Yes it is very possible and not difficult to run two different versions of the same program (be they release or debug versions). I agree that this is an important need and am sorry that I misunderstood you.
Finally, the overhead of the JVM is a red herring
If so, it's a big fat bloated one.
And there is still a real benefit to being able to dynamically determine where code will run based on the capabilities of the client/end node device.
CORBA/DCOM will allow this but they don't transmit the code for those objects. Why Java? There aren't any features provided by it which aren't already duplicated in something else and which justify using an interpreter for system objects (remember that this whole discussion is about system components and interfacing them with application components).
Oh, as a final aside, ad hominem attacks aren't called for, especially when someone goes out of their way to state that thier comment is not based on extensive or first-hand knowledge. Thanks for your response.
This is a technical discussion, if you don't have any experience with a thing then you shouldn't comment on it. I am frustrated to no end when I see misinformation being spread and highly rated by people who have no experience with what they're talking about. To make matters worse the thing is highly moderated. Doesn't this strike you as frustrating?
___
The ends are ape-chosen, only the means are man's. -- Aldous Huxley
>Sorry, but you've got no defense here. Balsa, Mutt, even emacs will read mail.
And none of them handle multiple POP accounts. Mutt certainly isn't going to display that scan of the new baby in the message, or show a company logo at the top. I guess no one ever included pictures in snail mail either or ever wrote on letterhead either. But YOU have no use for these features, so they're useless, right?
I've finally had it: until slashdot gets article moderation, I am not coming back.
I profess complete ignorance of Eiffel, and substantial, if not complete, ignorance of utilizing the JVM for multiple languages. But...
Wouldn't implementing Eiffel to live in the JVM also require it to lose multiple inheritance?
[for the record, as a Java coder, I don't miss multiple inheritance]
As for Java, remember that the GNOME guys are all rabid free software zealots and wouldn't dream of depending on a proprietary language like that :). Nor do they have the marketing
team to force people to switch to another superior language (see
what happened to ObjC, Eiffel etc). So C compatibility
is really the only way to go.
Reply got attached to the wrong comment.
Probably my fault.
Sorry.
A Dick and a Bush .. You know somebody's gonna get screwed.
War is necrophilia.
Thank you very much for your informative reply to my comment. I will check out fte and jed and inform my friend so he can get on with setting up his firewall.
Jumping to correct solutions slowly is better than jumping to incorrect solutions quickly.
First, is anyone from GNOME talking to anyone from GNUstep? While approve of the Bonobo architecture ideas, it looks to me like the two are doing very similar things. (And WindowMaker rocks my world.) Second -- does anyone else think that an object-based OS doesn't really sound like UNIX? -_Quinn
Reality Maintenance Group, Silver City Construction Co., Ltd.
You got a hell of a point there, AC. Of all the apps on my Linux box, GNOME is by far the suckiest.
Information wants to be anthropomorphized.
Bloat!=Flexibility. You wouldn't believe how overbloated GNOME and KDE are. From my experiance, BeOS has a fairly complete application framework, with a lot of consitancy. It is also the lightest major OS available on x86 (with the exception of QNX Neutrino). (Out of *BSD, *NIX, Windows, etc) The major problem is that GNOME and KDE suffer from huge feature bloat. GNOME implements a file system, uses CORBA (trying to kill a fly with a Buick there) for objects, and in general puts in a lot of stuff 99% of people don't need. Consistancy does not have to be accompanied by huge overbloat. I just has to be designed with some sense of what would be better if left out.
A deep unwavering belief is a sure sign you're missing something...
The main thing is that in UNIX, too much policy is bad. Overall the lack of policy is done to overkill propertions in UNIX, but it is still a good idea. Also, performance comes first. Do you realize how god-aweful slow a CORBA based filesystem would be? The thing is the more you abstract, the more performance you lose. Up to a certain point it's a good idea, but beyond that it's not such a good idea. The component interface you mention is already implemented to some degree on OLE. As the designers put it, "OLE is 2/3rds of an operating system." However, using to it's full potential is a very performance robbing proposition.
A deep unwavering belief is a sure sign you're missing something...
Is it so strange that the GNOME team primarily write GNOME components? GTK+ is a small and fast widget set and I think huge complex components like the GNOME canvas is the last thing it needs.
I have nothing against the GNOME team writing GNOME components. I do have a problem with them writing incredibly useful components that could be used at a lower level than GNOME. Now, it's hard to decide exactly what should get backported from GNOME to GTK+, but if nothing else, things could get separated out to only depend on GTK+. Then GNOME could use those -- much better code reuse. That keeps GTK+ a "small and fast" widget set and benefits those programmers who don't care for GNOME but would like some GNOME-type functionality in their app.
AFAIK the only "GNOME html component" around is the GtkHTML component (used for example in the Helix Code Installer, Updater and some wizards). I'm pretty sure it works in GTK+ only apps too.
Well gosh, why don't you check out the Debian package page for GtkHTML and explain to me how it only depends on GTK+. And no, I'm not concerned about the image libraries; those are pretty standard and easily compilable.
-Nathan
Some pieces that free software could do much better:
Re-inventing OLE / DCOM is silly. There's so much else to do with much greater pay-offs...
Perhaps I should have stated that a little differently:
The CORBA model for resource management is appropriate for its domain: big distributed applications. Basing Bonobo on CORBA sounds like a good way to get distributed applications, but if the cost is that you have to accept CORBA's model for resource management even among objects that are all on your machine, that's too much for me.
To a Lisp hacker, XML is S-expressions in drag.
Well duh, if you can't stand 2 weeks of "trashing out", how do you expect to learn anything intellectually challeging?
PCXL Forever!!!!
Hypercard was an interesting system, weighted down by a terrible scripting language. Hypertalk was painfully similar to COBOL-60, ("add 1 to a") and had terrible data access ("field 3 of item 4 of card 9341"). Hypercard also turned out to be a ripoff of Zoomracks for the Atari, so Apple had some problems there.
Hypercard's "component model" was weak; you couldn't write components in Hypercard. It was more like a plug-in system, and in fact most Hypercard plug-ins were to provide access to something Hypercard didn't support, like networking.
Hypercard didn't really lead anywhere. Still, Cyan's Manhole and Cosmic Ozmo, the 2D black and white predecessors to Myst, were written in Hypercard, an impressive achievement.
Now, I hate Windows as much as any loyal /.'er, but Microsoft has made a concerted effort to make object-oriented programming easy on their systems. It may run like crap and be painful to anyone who knows better, but Visual Basic does make OO a breeze to understand and work with, and COM is so tightly integrated into Windows these days that you can't sneeze without hitting it.
So, where does that leave us, the Linux/BSD/(insert-your-*NIX-flavor-here) faithful? Well, we have a few options. We could continue to try to pile layer after layer of abstraction on top of the core system, ending up with something that's highly understandable at the top levels, but an ugly mess of spaghetti code in the middle. Personally, I suspect that much of the bloat and instability of Windows comes from just this kind of sandbagging. Alternately, we could leave all that new-fangled OO stuff to the boys in Redmond, and continue happily spending our days piping text from place to place.
Personally, neither of these sounds all that great to me. I think we need to step back a bit, and start working OO services in at the operating system level. C++, Java, and the rest of the object-oriented languages are here to stay, and they deserve to made the be equals of C, Perl, and assembler in the UNIX programming model. Right now, what we have are wrappers for a bunch of C libraries -- a layer of interference that shouldn't be necessary. From a developer's standpoint, it's much easier to feed flat data to an object than it is to feed an object to something that's expecting text; doesn't it make sense to put the power at the low levels of the system, then, and simplify as we move up?
That was no joke -- its an embarassing mistake! Thanks for pointing out my error. Ok, version 1.0.1: malloc and fgets. :-)
Could it be because of the level of complication involved?
No, this isn't a troll. I've tried to use COM when I was trying to build an app which would embed the Macromedia Flash ActiveX control to display, well, Flash. Going through the ActiveX/COM docs itself turned me off; I figured that I'd need professional help with at least two weeks of thrashing out issues on my own to get started on COM so I gave it up.
Your whole point is based on the freedom of the developer. That is not the best way to do anything of software. There should be a single, flexible, powerful model, and all developers should be required to program to it. I really don't give a rat's ass if that means I have to program for a certain toolkit (from a developer's point of view) if it means that all applications use the full power of the system toolkit and interact well together (User's POV). Compared to Microsoft components on Linux is still a pipe-dream. Where on windows most modern apps use OLE and COM and take advantage of the features they provide (not only objects, but scripting, and network transparency) and applications extensivly use the component technologies, you've got the current GNOME/KDE situation where there are different object models, no-one uses them to their full potential, and all the really important apps don't work well together. I want to be able to take a spread sheet from StarOffice and embed it into a GIMP picture which is embedded into a StarOffice document. Since neither app really takes advantage of the component model I can't do that. Also, implementing objects in high level languages would be insane. MS doesn't use Visual Basic for most components, the easiest language to use COM from is C++. Python would be terrible slow. Components should be lean, mean, fast, network transparent objects from which to build applications. Only if they meet these criteria (lean, fast and pervasive) will they succeed.
A deep unwavering belief is a sure sign you're missing something...
Just for clarification, could you specify what version of Windows you're speaking of?
Mostly I was referring to 95/98 they're the ones I have the most experience with, except at work. ACL is pretty nice, because most of the time when I'm on the machine I can do whatever I want, but only when I'm on the network do the start getting rigorously inforced.
As for number one, BSODs are typically caused by bad drivers, or bad third-party software (ie, stuff not under MS's control). I've had my own share of segfaults and such in various unices.
Yes there are a lot of problems that Microsoft doesn't really have control over, but it's so much easier to blame them:) And yes I have had the same problems through the years with UNIX systems, but usually not in this number. I do have to admit that with NT and 2000 I have had better luck, but I'm not going to lower my expectations just because the system is a complex almost impossible behemoth that no one person alone could understand. Wow, I guess I do have management potential after all.
Addressing number 4 in the list of "Bad" is simple -- Windows 2000 has a tab on the Task Manager to show all processes, with customizable columns.
What I was referring to was under 98 when I look at the system manager there are various programs that exist as drivers but are programs and when my system gets unstable I try to kill them, and their names usually aren't too verbose on what they do, though after a while I can kind of figure out what they do. I had had some "issues" with 2k which caused me to shy away from using it (they have been eliminated, but once bitten twice shy), although I do admit it's way superior to both NT and 95 IMHO.
For number 5, who said you have to write Win32 code?
Nothing, it's just that what I'd like is something as easy (in my mind) as java to learn that wasn't a resource hog (java). I just thought it would be nice to have a windowing system that people could program as directly as possible to the windowing system, but yet be able to learn it as a first experience to gui programming. (I program embedded systems for a living and gui coding is in my mind needs a different mindset when you do it) I guess this is wayyyyy too much to ask, but I figure why the hell not ask for it? More proof I can be a manager.
As for the problems with the GUI (X), the only sane solution is to get rid of it!
Preach on.
Of course, that's never going to happen.
While I pretty much agree with everything you said I wish I didn't have to agree with this. Not that anyone is reading this thread at this point:)
"Doctor's mistakes you bury, Engineer's mistakes you live with forever."
I agree, however, with much of what Cory said about /etc files as "global variables". If only on aesthetic grounds, I like the idea of each program putting most everything into a single directory. A notable exception would be most forms of user data -- I certainly don't advocate putting every file I edit with XEmacs into the same directory as the program files. True, a lot of information about a program does need to be available quickly at some centralized location, such as a list of available programs. That creates a mess of trouble, but not nearly as much as the ad-hoc global-variable approach we have today.
FWIW, the idea of using XML as a config-file format was also briefly discussed. IIRC, the response seemed to be that the developers preferred to stick with a vi-editable text file in the old "keyword=value" format. Oh, well.
--Will
But usually autodetecting a format just looks at the first couple of bytes yes? Most config files don't use #! or magic numbers or anything so you can't reliably discern anything other then wheather or not the file is text or binary.
KidSock
Imagine for a moment a database system that presented two interfaces. The first is your typical database interface: a database connection, SQL queries, transaction and concurrency control. The second interface allows you to simply log into the database and edit any table by hand---no transactions, triggers, referential integrity, input validation and so on. The second interface, used alone, could actually work, but it would require the users to adopt to a sound policy, i.e., manually implement all of the features of the first interface. Obviously, the first interface is preferable and used alone will help result in a stable system. If the two interfaces are used together, you have a disaster, because users of the first interface would assume that the database system is enforcing policy and would trample on users of the second interface, with database corruption the only outcome.
The answer is to get rid of the second, direct interface and force everyone to use the first, policy-enforcing interface. That's why I think we need to get rid of (gulp!) the current UNIX file system model. Current file systems expose a hierarchical name space, but it is too closely tied to the physical storage (partitions a prime example---yes I know about logical volume managers). Furthermore, the hierarchical name space is too difficult to index and search effectively (witness [s]locate which does not update its indices on each file system transaction, but has to be run at regular intervals). So Miguel et al's idea of a component based configuration system is great. Except that it is too high level and leaves the standard file system interface intact. I suggest we need a single component interface to access system resources. (I'm mostly thinking of files, but the idea can be extended.) A first step in that direction might be to create a CORBA-based file system (basically persistent object storage). NFS wrapped the file system interface with RPC. CORBA is (in part) object oriented RPC. Seems a natural way to present resources as objects/components and provide a policy rich interface to these resources.
I agree completely with this philosophy that components are a good thing. Yet generally in the details of a proposed/implemented component architecture there is something dissatisfying about it. Here's what could be learned from the Unix command line in the component world.
The lack of policy in Unix piping has been a good thing for the long-term survival of the architecture. Policies in an architecture naturally gravitate towards one class of problems, i.e. providing a consistent GUI for embedding GUI controls and document display components. To me, most interesting Unix programs are the ones you _can't_ see. Sorters, searchers, counters, manipulators, etc. before the printf() ever happens. Daemons, protocol stacks, moving a stream of bits from point A to point B. The universal "everything is a stream of bits" model is very powerful and universally applicable to nearly any computer problem, including the UI and configuration issues. It allows Unix to be a bridge between TCP/IP and SMB and Appletalk and Netware and DECnet with no integration programs required. Which leads to my second point:
Where's the component analog to the command line? Why do I have to be a programmer to use the Bonobo components? Here is opportunity to leap beyond COM and create something new and powerful. I can easily tie unrelated Unix "components" together with pipes at the shell.
Here's a crazy idea... what about having some kind of component-aware kernel and shell for interactive use? And what about the possibility of building applications through application definition file(s) in the component shell? I'm talking next generation shell scripts, connecting CORBA components together instead of regular open/read/write/close programs. Is Bonobo universal enough to give the user this kind of power? For example, in the component realm, can I pipe XML through a content-aware sorter and through an XML-HTML converter and then into a browser component on demand? Can I quickly add a context-aware word count to it? Can I modify my mail deamon and quickly remove or install a SPAM filter component from the inbound mail pipeline? If you could provide interactive component reuse to the non-programmer, you'd have something far beyond COM.
As a realitive Newbie to Linux/UNIX myself, I find the whole system clunky and dificult to configure. I do have high hopes and am glad to see another OS finaly worth the trouble, but it's a pain in the ass. I'm making my way through it, but it's not something I would put in front of my parents/friends and tell them to use yet. I'ts too easy to sit on a high horse and tell people it's not that hard, Windows and Mac users have been bitching at each other for years about this, and the short point of it all is: you know what you know and are scared of anything else. Most people are just not "tinkerers". they want something that works out of the box. I can't see UNIX ever getting that easy to use, but I think Linux is almost there.
Dirty Pirate Hooker
This Post Is Way Off-Topic :)
Having Cherokee Indian blood in me, I don't see it as racism, for a couple of reasons:
One, there's nothing wrong with Indian. In fact, most Indians prefer Indian to "Native American". They were called Indians not because Columbus thought he reached India, but from his log, which he described the natives he found as being "in dios" (with God). (Columbus's spanish wasn't terribly good) I think that's a lot better than naming them after an Italian cartographer.
Two, the colloquialism "off the reservation" is an old one. I have no idea about it's origin. I use it because it best describes what happened -- Miguel, a true hacker, has wandered off the sacred tribal grounds and is basically throwing stones at Unix.
I wasn't trying to be offensive, just, as you say, "colorful".
As a side note, the Indians have more grounds than anybody in this country to bitch and moan about how they were treated. This is why I like Tribal casinos -- I like the idea of the Indians losing their land, but getting money for it from fat-assed yahoos from West Undershirt, Ohio.
Potato chips are a by-yourself food.
Even the COM purist at Redmond break their
own Law of "Inmutability". This is what's needed
if you don't know which version of Excel
you're working with:
pXL.CreateInstance ("Excel.Application");
vt.vt = VT_BOOL;
vt.boolVal = TRUE;
#ifdef _EXCEL_9_OFFICE_2000_
pXL->PutVisible(0, vt);
#else
pXL->PutVisible( vt );
#endif
- Ernie
Isn't it funny he mentions this little detail....
It's one detail that although many GNU advocates think they endorse, they really don't.
Before you start flaming away, think about it? Why did the TCP/IP stack become wildly popular? why did BSD sockets became the most used? Why did X catch on?
To all those questions... there's a simple answer...
They have a free license, which allowed programmers to take the good concepts and apply them to newer designs... NO , it's not stealing code, since most of the time you can NOT take someones code and apply it without great modification to another system, it's true code sharing, and something that betters the industry as a whole....
This is why people object to the GPL, in a perfect world, sure it would work, but in an imperfect world like ours.... you should not, and people don't like to, be forced into releasing your work, just because you used someone else's concept
Hence, why the X license and the BSD license help the advancement of unix, and why licenses like the GPL actually promote the splintering of unix...
Of course, this is my opinion.... ( am alwasy right) hehe..
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) and Java desktop apps (e.g., JFA), we'd soon have a good environment that would be much easier to extend with new components than a big C/CORBA system.
Let's forget the fact that Miguel did use the word "suck".
OK, now, the rest of this document highlight some features that Miguel'd like to see in Unix.
IMHO, some of these features could be worth coding. And accepting that we don't have them unlike others is fair.
If we want to prove him that Unix doesn't suck, well, just prove him that Unix is open enough to easily embed the features he asks.
These are reasonable features that would certainly benefit Unix, and Gnome in peculiar (by "benefit", I mean bring their users to new levels of computing ease).
I personaly enjoy it and understand Miguel's message as a challenge.
--
Trolling using another account since 2005.
Didnt we just have an article on how horrible it was that windows ME doesnt have an easily reachable CLI mode anymore.
I for one dont like graphics screwing with the resources of my production servers. As an admin. I enjoy having as many free clock cycles on hand as possible. there never seem to be enough!!!
I'll probably get downgraded to flamebait, but...
... it almost seems to me that article was more about how wonderful Gnome is than how to improve Unix. In my experience, Gnome creates at least one new problem for every one that it solves. It is bloated beyond belief. My new computer is a 2x600Mhz that runs X at the exact same slow speed as my old 1x300Mhz thanks to the fact that it came pre-installed with Gnome.
Additionally, all of these wonderful libraries create dependency problems that make it virtually impossible to upgrade your system or install any new apps. Every time I've tried to sample a new or upgraded Gnome app, it tells me I've got to download a new library. But since all the libraries depend on each other you end up having to download at least half a dozen huge files. It is ridiculous that even the simplest of apps depends on so much megabloat code.
And the only way any of this stuff will define "policy" or encourage reuse is if Gnome is the 100% development standard, something I think is unrealistic.
The dude is right...UNIX and its variants are a small part of the market because their target end-user is the advanced/expert programmer, not the Average Joe Schmoe who prefers a pretty GUI interface and simple usability.
It's not that UNIX sucks...its more that it simply sucks for a particular kind of ppl (namely your average computer illiterate end-user) whereas Windows on the other hand any 6 year old can use.
Most people favor simplicity over anything (stability, power, usefulness, etc). And despite the fact old-school UNIX zealots will jump all over this one, GUIs and "helpful hints" and user-friendly crap like that _are_ easier for 90% of the population to deal with (and is one of the largest reasons windows holds onto a majority of the users out there...well that and the gaming issue...damn i wish more games were ported to Linux/UNIX)
Not meaning to flamebait, but he spoke with a lot of absolutes, referring to code reuse and various things of UNIX GUI. I'm just curious if he's so involved in GNOME that he doesn't pay any attention to KDE or was he trying to disregard their efforts as insubstantial or very non-earth-shaking. Because KParts in KDE is a very elegant to develop for, and speedy to use component architecture which is in effective use extensively throughout KDE2 especially KOffice where there's live embedding of KOffice documents into other documents, and in Konqueror the viewing of images, movies, KOffice documents, PS/PDF files, and tons others are accomplished through KParts. It seems to me that with so much accomplished on at least one of the centerpoints in his Talk/Paper, his ommission of the KDE effort was either ignorant or calculated.
where'd my typewriter go?
I just wanted to weigh in with the fact that I got interested in UNIX in general and Linux in particular *because* of the command line and the generally wack interface, not in spite of it. It's true that when I'm in Linux, I'm nearly always in X, but I do all my file management etc. in an rxvt, not an Explorer-type file manager.
I must say that I do lament the lack of a standard application framework that would give some consistency to most programs: same hotkeys, same type of menu bars, etc. But, if to get that I have to put up with all the extra crap that comes with GNOME or KDE, plus having to continually update such a huge and rapidly changing chunk of software, I'd rather just tolerate rampant inconsistency.
MoNsTeR
For those interested gnome is at: http://www.gnome.org/start
My specs: P300 128 RAM Voodoo3
At the moment I have both Gnome 1.2.1 and Kde 1.92 and I must say there is no difference in speed between the two. 1.2 has added several eye-candy features (read: good to atttract newbies) and just improved the functionnality of core apps, especially GMC.
Gnome is not bloatware anymore even for my middle-end box. Good job to their team
--
Kiro
1)We should be thinking about ways in which the UNIX philosophy is deficient, rather than continually reassuring ourselves that it's all okay. Look at it pragmatically: Who's got the biggest market penetration? Who's system is easier to learn to program in for the beginner, ignoring cost?
UN*X is a tool. Like all tools there are different tools for different jobs. I think comparing UNIX to MS's products is foolish because they are designed for completely different purposes originally. Maybe what we need to do is develop something that is single-user if our main objective is to crush Microsoft, but I don't think that is what I use Linux for. I think what we're tired of is not having the flexibility in MS's enviornment to yield the true potential we think is in our machines. I am also of the personal belief that X-Windows and window managers sometimes can make me swear more than any MS product can. What I want is speed and power, and I don't want to sit for days trying to figure out how to tweak it to my needs. Just fix it one way for all Window managers and stick with it. Let people tweak it if they want but first make them all look basically the same. Frankly I'd rather learn how to adapt to a window manager once so that whoever I logged in as I could be as quick as I am when logged in as myself. No matter what box no matter where.
Okay, these are total flamebait questions, so please, please don't respond to these in particular. Use your imagination, and think of some ways in which Windows is better than UNIX, rather than touting all the advantages of your pet operating system. Otherwise, you're just brainwashing yourselves with your own marketing.
Here is why I like Windows better than UNIX:
1) No matter what Windows box I sit at the controls are always the same. Emacs should have the meta key where the alt key is on most IBM PCs, but I never see it by default on a Linux box, and I know people on Sun boxen are a heck of a lot quicker in emacs with it. Also RedHat's version of gnome when you hit Alt-F4 goes to the 4th VT, this drives me insane after coming in from the cold of NT. Yes I know I can fix all that, but I shouldn't have to.
2) In windows I am (in a non-networked enviornment) root. I do what I please, no permissions, freedom like none offered by a UNIX system. This is not something UNIX should ever offer, BTW it's something only a single-user machine needs and a multi-user enviornment should probably never have.
3) Whenever I need help I just go to someone else around and they point me to someone who knows how to fix my problem. And stupid tech support people don't refuse to talk to me. (Yes I know if I read the docs eveything is explained. Try explaining that to some of the computer illiterates I've met)
4) Usually it's easy to aquire software.
5) A few clicks and I have a working non-postscript printer. Amen.
What's bad about MS Windows:
1) BSOD. If it isn't stable it isn't worth installing.
2) It's not designed to be a multi-user enviornment.
3) It's insecure due to the lack of walling between the user and his power to do bad things. I actually believe that UN*X provides stronger protections from the user shooting himself in the foot than MS Windows in some respects. (However in UNIX when I shoot my foot I tend to blow my lower torso off)
4) Windows isn't as visible to what is going on. A ps ax isn't available to selectively kill, sure you can do a vulcan neck pinch, but what the hell are some of those programs running? I have no friggin clue half the time. It would be nice if whenever you did something you could find out what the hell is going on. This is my same complaint about RedHat's linuxconf. I never have a clue of what it's doing and I usually end up regressing back to my slackware years.
5) Programming in Win32 is like smoking crack. I've got better things to do with my life.
6) I don't have lots of cool free software that Linux provides
What I think the community needs to realize is that maybe we should think about a couple of things:
1) Can we make a really good Single-User Operating System? I'd like something that let me f up the system completely but yet have everything laid out in an understandable fashion if I take the time to read the docs. To be honest, I never would have figured out Linux if not for the LDP. I however think copying MS's products is a waste of time, I think if we went our own way people would have to follow, just like they're starting to follow Linux, and maybe we could make an OS that even our Moms could understand and even possibly maintain. *SHUDDER*
2) Improving the front end for UNIX users, the GUI is the place to go, but what we really need to do is lock down a keyboard structure for all commands that will happen on the X-Windows. Frankly until this happens I'll get more and more frustrated because I don't have the time to learn how to program effectively in each new WM to come along. Why can't we just agree on some type structure of keyboard strcture for the gui where by hitting a single key with no windows in focus magical stuff would happen that would save us from using the mouse. Then standardize it. I don't care what window manager I use, I don't care about the licensing crap, I don't care about your internal struggles over programming methods, just make my life easier, let me use the keyboard more, and the mouse less. The speed of the keyboard is what makes UNIX powerful and the quicker I reach the state or nerdvana where I am one with my computer the happier I'll be. While tweakablity is a really good reason to move to UNIX a uniform command structure is the most important thing to getting any system used widely used.
3)At some point we might have to consider the fact that X-Windows, while it is a standard may have to be sacrificed at the altar of programming sanity. Just because it won the race due to the availability of it's source doesn't mean it is better.
I know this is a lot of flame-bait especially since I can not offer solutions. I thought however I needed to say what I thought the problems were, so do with them what you wish. Someday maybe I'll actually achieve nerdvana. *SIGH*
"Doctor's mistakes you bury, Engineer's mistakes you live with forever."
Gah, this keeps coming up. People bitch about COM & CORBA's implementation difficulties (and I agree, to a large extent) but the idea is so compelling. I read some propaganda for SOAP (XML-activated objects) and it sounded good. But wouldn't reliance on an XML structure just put people back into the soup which motivated the switch from operations on data structures to operations by data structures (objects)? That is, back to a COM, CORBA model? So they can make more money? So they can buy more cocaine? So they can make more money?
Will advancements here be incremental improvements to COM/CORBA, or is there something cooler on the horizon? It seems that a platform that offered a real working solution to this issue could provide both power and ease of use unmatched by any other. Do any ivory tower CS types have any thoughts?
Kill, Tux, kill!
Ah, but why do the usual thing? :) Just look at the whole file and make a good guess... If nothing else, since all config file formats support user comments, it's easy to make the rule that some unique identifier string must exist somewhere in the file, say "$Config file format: Foobbed 1.1$".
But we digress. The more interesting thing about the application is not the format of the config files but in the way they're used by the system... It'd be so nice to have all program data self contained in one directory structure: binaries, libraries, man pages, docs, and config files. And, to have a very simple, standard system component that allows a package to modify it's own config or inspect another package's config with minimal programming overhead. It would never become standard unless it's so easy to use, someone would be brain dead not to use it.
First and foremost is simplicity in every direction: simple installs, simple uninstalls, simple configuration maintenence, simple package relocation, and simple to implement within the program itself. Only after the simplicity guarantee and the proof of concept should bells, whistles, and other handy features be added.
So no, xml may not be ideal for every config, but it gets the job done. And I'm with Miguel 100% that a nice, standard GUI should be primary method of modifying various config files. In the case that a user needs to hand edit a config files 0.01% of the time, there's no real point in supporting multitudinous file formats. It'd just be a bit of icing on the cake of an elegant solution to a problem most people don't even realize exists...
Quick sidenote: I will admit to a wording snafu (fu*kup) this message was not meant to flame your credentials
PX: I heard little about Miguel prior to 3 years ago which leads me to believe that he has never really worked with too many UNIX systems.
I should practice what I preach by "thinking before I type".
Yes, there are people who will screw it all up, but there should be ways to compensate for these people. I don't really know how, but I'm not a user interface person.. and I think my vague ideas about how to compensate for these people will be made more clear by answering your other point below.
Yes, GNOME's source is available, but GNOME still tries to be a black box. The point is not *can* you script, but how *convienent* is it to script. A VCR with easy to replace ROMs and an assembly langauge compiler for a PC to create your own ROMs is not convienent since it requires you to learn a new way to control the VCR. Simillarly, a GUI with C++ bindings to write scripts is not convienent since I must learn a fundamentally diffrent way of interacting with my existing software. The real power of shell scripting under Unix is that you have been using the shell for years and everything works the same in a script as in interactive mode. My unserstanding is that Mac and maybe NeXT are the only operating systems to attempts a real "GUI scripting langauge" lke I'm describing.
Now, I should admit that I do not realy know how to do a GUI scripting langauge, but there are several ideas:
(1) force everything to use CORBA in predictable ways, so it's easy to pick out the useful core modules of another program and exploit them. This is probable the best solution, but unfortunatly people seem more interested in CORBA for providing stupid GUI widgets instead of structuring our programs to provid a nice library like interface to external programs.
(2) force everything to use a command line interface, but make your cut-n-paste so effecent that pull-down menus can be implemented via cut-n-paste. (Don't laugh. Plan9 tried this. It's one of the most bad ass things I've seen from a traditional shell users point of view)
The Christian religion has been and still is the principal enemy of moral progress in the world. -- Bertrand Russell
As other people have pointed out, reference counting is the way COM manages these things--- and it almost, sorta, kinda works for a little while in the demo and on the LAN. Perhaps the gnome guys just want to be bug for bug compatible.
Reference counting is a bad idea whose time has passed. When faced with the inevitable programming and network errors reference counting leaks. In some circumstances these leaks are just little bits of memory and don't really matter (if you don't mind poor performance and restarting every now and then). But sometimes the leaks are locks and expensive things. Leaking these can easily lead to deadlock. Deadlock is as hard problem as distributed garbage collection. Don't go that way. Don't allow leaks.
Corba objects can typically timeout and save themselves to disk and be transparently reinstanciated when needed. Thats good enough for some objects; if you don't mind leaking disk space.
A leasing model works well. The client wants a foo for 500s. Great. Maybe it wants to renew. Also great. And if the client disapears without a trace (somebody hung up the modem or tripped on a cable or went out to lunch or whatever...) the server is free to clean up that foo. If it needs to, the client maybe forced to get another foo. Thats ok.
Most programs in most languages leak their own memory. Why would you trust those same client programs to meticulously solve your distributed garbage collection problem? If you are a defensive programmer, you don't. Even if you did, you wouldn't trust the internet to have 100% uptime; it doesn't. Instead you use leasing and/or timeouts.
Cheers, Henry
/etc must die.
/etc and /usr and /lib structure was spawned from the mind of a C programmer in which global data is deemed an acceptable solution. /etc is a form of global data, which is fragile and inherently carries minimal context. It's fragile in that there's no standard interface to retrieve config properties - so that any program other than the parent of the config file cannot reliably expect to parse it. And, without context, it's unclear which programs depend on a particular config file.
/etc!
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
The protocols are completely documented. Go to an on-line bookstore and look for them.
Realizing this is a troll, (and we aren't supposed to feed them) this is the common misconception that is so common it has in fact pervaded even some Unix advocates. We don't need to make a system 'more like Windows'. I remember MS saying that NT was a 'better Unix than Unix'. Should we now repeat that mistake by saying we are going to create a 'better Windows than Windows'?
:-).
The fact is that at some point we have to drop the idea that only what 'is' is all that will be in operating systems. Unix isn't the only system that sucks. And I defy you to give me a system that doesn't suck at the moment. Sure, there are ideas out there that address some of the suckage (TUNES tries, but again seems to 'not get it'), but for the most part, even the best ideas get dragged down in the 'backwards compatibility is all that matters' symbolic idealism.
Bring me a new system. Bring me a fresh start. Bring me a system that doesn't suck. Then I'll start pointing out why that system too sucks
Seriously, we use the tool that works best for us at the moment, but don't let that hold back your imagination from something else. There are a lot of problems in the *nix world. In fact, there are so many that we may be at the point where it would be best to drop it all and start over (in a *better* language than C even?). It's going to take a long time before enough people/developers realize this to actually make progress on a system that *won't suck*. And at the moment, that is what we need to consider.
Bite my yammer.
Point taken, for now.
There are NO games
- /usr/games
- Take a look at the FreeBSD Ports Collection under "games". Here's a link. Sure, most of them suck. Deal with it.
- Most geeks are too busy writing scripts'an'programs'an'config files'an'nat to do *real* work rather than write games. I haven't seen too many games written by DMR, Eric Allman, Kirk McKusick, RMS*, et. al.
If I wanted to play games, I'd buy a Dreamcast and put it in my cubicle. And even then, I'd be too busy trying to help port NetBSD to it.At the most the average geek has an xpilot or freeciv session running.
*-If you don't think emacs is a game itself
DrQu+xum: Proof that the lameness filter doesn't work.
Wow.. And I thought the /. bias wasn't that bad.. We're about 40 comments into this story already and every one that has been moderated up is people saying "Hey, come on, Unix doesn't suck, Windows does" and they go on to compare the Strengths of Unix vs the Weaknesses of Windows. Just like Miguel was talking about in the story (which I'm sure about 5 of the people posting comments has read)
Now, why don't we all go back and read the article? Miguel is very very right. He's been saying some of the things that Unix zealots have been covering their ears over for ages now. Component architectures are vital to a good GUI, code reuse is key. One of the things that people insist on doing in Unix is reinventing the wheel every time they need something done.
I'm glad someone who can't be ignored by the community is finally saying all this. Maybe someone will listen for once.
Nothing is perfect that includes *NIX
There alternatives are a MS only software/web, MS media format and such shit everywhere.
And no one is going to take away CLI from you.
Dumbing down Linux is a GOOD thing for everyone!*
Linus said something like this:
He who controls clients will control servers...(think MS media server).
*except ElITE dudes who only runs Linux becuase its cool.
Although I don't completely agree with Miguel's solution, it seems like a legitimate proposal, just like any other projects undertaken in the free software world. Just one thing to keep in mind, though - don't force the rest of us to accept his solution. Some of us like the way things are so open-ended as is now. Some of us don't like the unnecessary layer of abstration brought on by CORBA. It's good to have choices and to be free to choose among them - that's the most important thing, I think.
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.
To a Lisp hacker, XML is S-expressions in drag.
Under the "Unix Problem" Miguel tries his best in a few paragraphs to expose the history, and weaknesses of UNIX. I find this quick leadin not only completely flawed but mostly wrong.
He says that three years ago
"No innovation was happening". Which is odd because I remember running BSD and Linux in the early 90's - even before then my SGI hardware was bad ass and could whomp on whatever Macintosh, Amiga, or Atari ST could produce.
"No code reuse was happening". This is not only untrue, but downright weird to even think about. He states later that the systems developed (interfaces, abstraction, etc.) were flawed - even if they did reuse code - why would you want to? Code reuse is up to the program managers and programmers in a business model or the leaders of the project in the open source model. I do not see his point.
"There was a lack of basic facilities on the desktop". Well duh, you can't just say "here's a new OS - everyone support it". Linux has become popular and people run it, that's why there is support for it. Which leads into his next statement "The little innovation that was happening was proprietary.". If something is going to exist in a business model it must have support - this is why it was proprietary. More and more companies are being able to innovate in UNIXland because support is so wide - largely due to the open source model.
Later he complains about "Unix Components" - where they don't share "any code except for libc". This can be argued both ways. These sort of programs are as basic as format, fdisk, and tree. These are not designed to share code, they are designed to be small and singular. He makes the jump of ftpd to ghostview to Internet Explorer. This is not only unfair, but flawed logic. One is a service, which does not need a gui - one is a very old application (much like notepad in windows) and the other is an application that has taken a long time to kludge together.
My problem with this paper is that he just does not get it. He understands a *lot* about how to build GUI's and how to frame together a Rapid Application model. In this sense he is genius, yet in another he just doesn't seem to understand WHAT it is that he is building on top of. He complains about xlib, libc, services, and all the like. He doesn't look at the standards that were developed way back - such as POSIX and WHY they were developed, and *how* we got to where we are. He simply asserts that 3 years ago was "dark ages" and that today there is hope. I heard little about Miguel prior to 3 years ago which leads me to believe that he has never really worked with too many UNIX systems. If he wants to make a GUI, or even a GUI framework like X then great - more power to him! But I wish that Miguel would think more before he talks on subjects such as these because most people will simply flame him.
Please Miguel, think before you type.
If you spend much time looking at .NET, you'd realize that it's essentially built on top of COM itself.
.NET, let alone transcending it.
You need something like DCOM implemented first before you can even think of implementing something like
DNA just wants to be free...
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
CDE has one major strike against it in the Linux world: it's not Open Source. You have to license it from OSF. So, just like Motif, it can not become a Linux standard.
Tim
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.
Potato chips are a by-yourself food.
That was a very, very good article by Miguel. Unfortunately the first few posts I have read are from posters who obviously didn't read it and instead are making personal attacks at Miguel.
.NET for one reason only...cross language inheritance. The thought that my C++ components can be inherited by my Perl, Java or Javascript objects makes me extremely *CENSORED*.
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.
Once this is done, anyone can use it regardless of what language it was written in, fast XML parsers can be written in C++ and used in from Javascript or VB. This way developers of business apps do not have to make the choice between a.) putting up with a slow app or b.) writing one themselves with all the attendant bugs therein especially if they have little C++/C skills, also they can go on towards actually creating their application instead of worrying about if they malloced() enough space for their char*'s.
Lots of *nix people believe this implies laziness but fail to realize that reinventing the wheel dozens of times over is folly.
Example I:
I am currently designing and implementing a project management system on Windows(TM) for a small business with a few of my friends. two of them are *nix hackers and they balked at using an XML based protocol to transfer data between the client and server. Now instead of simply designing our protocol then using one of the dozens of available parsers to do this, they decided that we should invent our own binary protocol and write our own parser to parse it.
Our project involves code written in both C++ and Javascript/ASP. We could have used a single COM based parser to consistly interact with the data both from the C++ and the Javascript code but instead its been 2 weeks and counting and our homegrown parser is still being written, tested and debugged. In my opinion this is nothing but a waste of time. When I ask them why not just use XML and an already existing parser their replies boil down to "It just feels wrong.". The chances that a bug or two will slip through in testing or that there is a buffer overflow in our parser is not unlikely considering that most early versions of parsers written in C++ have a few bugs like this hidden somewhere. in this situation component based programming would have allowed us to focus on building and designing our actual application instead of focusing time and energy on a tangential application.
Example II:
At work a MBA intern asked me if it was possible to create an application that housed a search engine that searched a database of MBA students based on criteria like concentration, work experience, graduation date, etc. and then displayed results with links to their resumes in MSFT Word(TM) or HTML format which could be stored on a CD to give recruiters at career fairs. Their first attempt had been to use VB and Access which turned out to be a disaster because of DLL Hell based issues. My simple solution was for them to store all the students in an XML file and to write a Javascript page that used the COM based XML parser (written in C++) to perform the search. Writing this page took less than 2 hours.
Now they have this search functionality they can press on a CD and give out at career fairs which any recruiter can view without needing more than MSIE 4.0 or greater.
Without Component based programming their request would have been impossible to fill in their time frame and would have also required that the recruiters machines would need to fulfill a stricter set of requirements (like a Webserver being installed or they'd have to install an app).
In conclusion my question is "Why has it taken so long for a major *nix push towards component based technology?". After all we've had CORBA for almost a decade but there hasn't been that much a big push towards components. Frankly I am eagerly awaiting MSFT's
FOOD FOR THOUGHT
I think that we'll find out that the MS VM is going to force languages to make severe sacrifices to be compatible with each other. Look at the eiffel implementation (called eiffel# of course). It gives up multiple inheritance amongst other things so that it can live in the VM.
A Dick and a Bush .. You know somebody's gonna get screwed.
War is necrophilia.
Why can't we have our cake and eat it too? People seem to think if we have an intuitive iterface we'll lose out on functionality, I don't agree.
I want all the functionality we have in Unix but I want an interface that kicks some serious ass. I don't think its too much to ask to have both.
There just hasn't been enough improvement (innovation) in the *nix GUI, or innovation in linux in general. Thats the only real problem I see in linux, it seems everything designed for linux is trying to be a clone of something commercial, the developers are reacting not acting. Don't get me wrong I like the fact I have a choice in what I run and I can replace most stuff for free, but if linux is ever to surpass Microsoft or Apple we need to have good original ideas and provide the software people want/need before everyone else.
When you think about it though the free part is the whole mentality that spawned linux, "I can't afford to buy a real Unix but I can download this linux thing that doesn't work quite the same way (or as well, at least up to a year or two ago) but it's free and I can still do most things I want to do with it."
Trust me math labs at schools love this, they are full of technical people who can usually understand how to maintain a system and most of the ones I work with write their own code for research.
But everything they use for linux has a commerical counterpart that kicks butt, guess which is better/around first. Actually the good profs usually have enough money from research grants to buy the good compilers and there's still no free replacement for Matlab or Maple/XMaple.
Sorry its late but I guess the whole point of this post is:
1. People think that providing a great intuitive interface is going to eliminate the functionality we've come to know and love in linux. I disagree, a great interface is one that anyone from a new user to a kernel hacker can use and feel comfortable with.
2. There is a lack of innovation in the GUI department (DUH, anyone could tell you that, we're just rehashing MS, who stole from apple, who stole from Xerox Parc....)
3. Linux and free software in general is a copycat of good commercial software (heck sometimes the free version is better) and if we don't want it to be a nitch market this needs to change.
One last thought the GPL is the most revolutionary concept around, and we wouldn't be anywhere close to where we are in GUI or anything else if it wasn't for that.
Sleep Calls
Mac OS X will, for all practical purposes, be a non-sucking version of Unix.
I am Slad.
Of course, Miguel's original claim to fame comes from the sterling work he did on the Sparc Linux port many years ago. Due to his recent work with Gnome, few people realise how talented a kernel programmer he is...
"The invisible and the non-existent look very much alike." -- Delos B. McKown
Well, since Posix is a standard, and standards descibre rules about the way a system works and therefore dictate how someone should do something, I think it's a little disingenuous to make a crack about Microsoft when you're talking about Posix. Rules about how a system works are a good thing.
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
Linux on the server: happy happy. Wouldn't choose otherwise.
Linux on the desktop: does indeed SUCK.
I've been using Unix in a server environment since 1992. Never had any major problems. On the desktop, I started with Mac, fiddled with NeXT, tried Sun and DEC workstations, and eventual moved to M$ Windows (for gaming, nothing else compares).
All of those OS's have their strengths and weaknesses. And, in hope af creating a better world, last week I bought an extra hard drive and installed Linux (RedHat 6.2, am told Debian is better but no CD available) on it to play around.
In general, a less than fulfilling experience. Here are my observations:
1. I have to choose a desktop environemnt? GNOME or KDE? I'm supposed to know which has better Apps? Great idea - split a limited developers pool among two environments - so instead of getting one set of applications that work well, we get two sets of applications that are in perpetual beta.
2. Web Browser. At no time while using a PC do I have less than 4 or 5 browser windows open. Trying to work without a functional browser is difficult, if not impossible. I just don't enjoy opening NN and seeing my available memory disappear. (Last week, Mozilla was declared dead - how could this happen when it hasn't even been born yet?)
3. Mail Client. I spent days looking for a mail client for GNOME which supported multiple POP mailboxes. I found a few, but they ended up in wild-goose chases for libraries to replace those which where outdated, too new, etc. Never actually got anything to compile. Heard there's a good mail client for KDE, which means I made the wrong choice back at #1.
4. Editor. Uhh, I use vi and emacs when there is absolutely, positively, nothing else available. Don't get me wrong, I first learned emacs over 8 years ago. But there are some basic functions which I rely upon that don't exist in emacs. Give me something like HomeSite on a linux box and you've got a convert.
5. Word and Excel. Regardless of how much other Microsoft software sucks, these two products are hard to beat. Also, they are practically industry standards. If you work in any office environment, you'll be sure to get these sent to you all the time. Of course, you can read them from your linux box - but if you want to edit them, it's lilo:dos yet again.
I use my computer to work. It is a tool which I need to function efficiently. I played with my new Linux Desktop for a few days, then when I had real work to do, I rebooted back to DOS. A real disappointment.
I know, it's open source, help and code it instead of complaining. I do code open source software, but for web applications. I don't code for the desktop. To grow, linux needs the desktop. To win on the desktop, Linux needs the killer apps - at least a browser, a good mail client, and an editor.
To get there, I'll argue that Linux needs less developers rather than more. I'm tired of seeing 2000 new apps which are v.0.0.0.1beta0.0.5-unstable. The paradigm of "release early and often" needs to be rethought. Release when you have a functioning application. If you have an idea for a new app, look around to see if anything else is out there first. If someone is already working on the same application, join them rather than creating a new tarball which will never get out of beta.
Open Source can and will take over. But it won't do so without the Desktop. And the desktop is all about applications.
It seems like a lot of people are missing Miguel's point. He is not saying that you *must* do it this way, he is just saying that this is just one way of doing it, a way that he feels is better.
What I see as one of the points here is that a lot of people are wasting a lot of time by writing a bunch of support code for their application because they are not reusing code. How this hurts us is the fact that this time could be used more effectively on working on the logic of the application, rather than rewriting yet another html parser or whatever.
I know on a few pieces of software I have written I ended up using glib, because there are just so many nifty functions that programmers are constantly rewriting. And I can see his point after using what is still a fairly lowlevel interface.
Also, as far as a lot of people saying, well we have pipes and that's all we'll ever need is just silly. I mean yes, pipes are neat, but god damn, how do you really expect to write anything complex and have it be relatively fast when your swishing data via pipes and firing off a bunch of new processes via fork().
Modularity is really the key to have a extensible OS. Linux to some extent is modular, but not really. Take a look at the HURD for example, from the design viewpoint, its a beautiful kernel. Sure microkernels are a bit slower than a monolithic kernel at this point, but what difference does say a 3% performance hit matter.
Code sharing and reuse is really what open source programs should be about. There should be common APIs and interfaces. Lets let go of some of the baggage that has accumlated with us over the years and stop trying to be a UNIX workalike and do something innovative. Linux and GNU are really the standards that the rest of the Unix community are trying to live up to now, we should show a bit of leadership here.
The hardware will make up for the speed loss. It certainly can't make up for the time I spend rewriting the same components other folks have done before because they aren't available in my language, or writing library bindings to python and perl and whichever other lib happens to be in vogue...
GNOME may not be a perfect answer right now, but that doesn't make it not a Good Thing in the long run.
The fundamental problem with *nix is the chaotic file structure. Darwin has done more to simplify this than any other *nix implementation.
.file in the home directory, then trying to decipher it. Every property list in a bundle can be an XML for easy editing as well.
/etc/ directory. Instead of editing your various group, passwd, shadow, UID, etc. preferences in files littered about in your /etc/ directory this data is stored in a database which can be edited manually or by importing files inthe typical /etc/ format. There is also a method to authenticate a user without having read access to the passwd.
Bundles:
Bundles are one way Darwin tackes this problem. Headers and libs are no longer disassociated, rather the library and headers are bundles together and placed in ordered locations according to their function. Kernel modules include a property list outlining their dependencies and what service they provide for problem-free use. The module loading daemon automatically loads modules when necessary. Startup items are also modules which allow for perfect ordering according to dependencies and load preference, plus they are all placed in a specific directory which allows easier editing of startup preferences.
XML:
Virtually all preferences by either system, services, or applications are in XML. This allows the preferences (located in a specific directory, of course) to be viewed with ease. No more hunting for the right
NetInfo:
NetInfo solves the problem with the littered
IOKit:
Drivers have been organized into a tree of hardware services. For example a USB to SCSI bridge uses a USB service and provides a SCSI service. It's very leet.
In summary I don't think the gnome people have done their research like GNUstep has. They started with an arrogant approch of re-inventing the squared off-center wheel and sometimes peeking at the chaos which is windows. Better to support the GNUstep project instead.
---
>80 column hard wrapped e-mail is not a sign of intelligent
>80 column hard wrapped e-mail is not a sign of intelligent
>life
When most folks port Posix programs to Win32 these days, they tend to use Posix libraries so that can still get at the Win32 API when they need it.
This man obviously has no common sense, - He dosnt mention KDE and their efforts at all. - He talks like he has uncovered some mysterious revelation that will change the face of Unix. - Reusing code ? Why didnt he join the KDE team instead of starting the gnome BimboWare project. ( Thank god that didnt happen, shudder to think what kde would be like now) And whats that about unix sucking ? I used unix first. Windows, which I never ever liked, is too hard to do something usefull with. Linux is much more logical and easier to learn, all you have to do is read a little. Alot of emphasis on free software, while at the same time.... HELIX CODE $29.99 Maybe he's just trying to get pubilicity to sell more $29.99 free software. whew...
I agree that code reuse will bring more apps better and faster to Unix, but can this be implemented without being vulnerable to lovebug-like viruses and exploits? Linux tends to be very resiliant to such things thanks to the independence of the components in the GNU/Linux environment doesn't it?
I'm not entirely sure whether or not this is a troll. If it is a troll, it's a bad one. Great moderation on this one guys :cough:.
;)
I'll address your points anyway since it may clear up some confusion that other people have.
I'm far from a Microsoft programming expert, but I think I'm correct in stating that although these interfaces have indeed remained static up to now, this is more due to a design flaw than by design.
You ought to look at the actual interface definitions. The interfaces in the OLE spec are incredibly generic. This doesn't mean that more specific interfaces can't be written but, as far as OLE is concerned, the idea is to provide generic wrappers for a couple of types of objects. Things like in-place documents, controls, and scriptable objects are examples of the things that OLE allows. Before you comment on the design of the interfaces (their being fixed in format so long as a sign of bad design? ha!) you ought to actually look at the design of the interfaces.
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.
Most plain-vanilla COM components are extended by exposing a new interface. This doesn't have to introduce bloat, however.
Consider IFoo, which provides the method "Bar." My Foo component gets used for several years and eventually I decide that IFoo is just not going to cut it for every way in which my component is used. So I come up with IFoo2, which includes a new member, "Bar2." How do I keep from introducing the "bloat" of having IFoo::Bar and IFoo2::Bar and IFoo2::Bar2? I inherit IFoo2 from IFoo, at the implementation level it doesn't make any difference. It's not bloated.
The other method of extending an interface gets us back to your 'poorly designed' OLE components, specifically the interface IDispatch. IDispatch is an easy way to get runtime type-information. You can get a list of the functions exposed by the object, their return types, and the parameters (if any) and THEIR types. Methods can be invoked in a very abstract way (passing in the ID number of the function and an array representing the parameters). This is more "bloated" (in that it's slower) than the IFoo2 method above, but IDispatch has the added benefit of being scriptable (in fact it's the interface behind every script interpreter that MS makes).
So there's your bloat.
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.
Have you even used Microsoft compiler products? There are problems, to be sure, but this isn't one of them. The dll search-path is well publicized in MSDN. If that isn't enough for you, it's really easy to:
#ifdef DEBUG
#define MyExternalFunction MyExternalFunctionDebug
#endif
If you're using late-binding, it's even easier. You don't need to swap dll files in/out of the system directory, you can just specify the full path to the file in your call to LoadLibrary. Of course, none of these methods have to be used within Microsoft's Developer Studio IDE. You select the target mode of your application (Release/Debug) and it will be compiled for those libraries. You can run both versions at the same time if you'd like (although God knows why you'd need to do that).
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.)
From whom at Microsoft did you hear this? A janitor? Dll's aren't shared between processes anymore (they were back in real-mode pre-DPMI days though). Dll's are mapped into a program's memory space when requested and are always loaded from disk. If you don't believe me, try it yourself.
This sort of behaviour *MUST* be avoided at all costs!
Yes! I agree! We *MUST* end misinformation and ignorant hyperbole!
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?
We'd still be waiting for it to load.
Seriously, you're not one of those guys who demands a Java OS are you? There really IS a level at which the indirection of a highly-abstract language outweighs any benefits it might bring.
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).
Portable binaries in and of themselves have the ability to 'dynamically define the client/server(s) split' how? Balanced tasks over a connection are what allow you to 'define the client/server split' (though that's really unimportant). Between two machines sits an ORB brokering method calls from one computer to the other. Which is the server? If you throw 1,000 components on one big fat computer and all the little computers use it, it's fair to call it a server. If components are daisy-chained around a network then it's probably not such an important distinction. I'm not sure how Java has much to do with this though.
Anyway, if you're so obsessed with doing it in Java (these are SYSTEM objects, why run them through a VM?) then you can always make the objects in Java.
So pick up a couple of books and write some code, eh?
___
The ends are ape-chosen, only the means are man's. -- Aldous Huxley
Upgrade removes old versions. Install keeps them.
It's hard to see how so many people are getting this mixed up.
Only if you are obtuse is it difficult to see how people would mix this up.
Many libraries packages, when one attempts to "install" them, report that they conflict with some older version of the same library. The natural thing for a user is to think "of course, I need to upgrade" and do so, promptly removing the older, conflicting package.
It is in no way intuitive to use "--install --force", particularly when "--force" is documented as being dangerous to use.
The default behavior of "--upgrade" should be to not remove the older libraries, but install the newer libraries such that they coexist, without offensive messages warning of conflicts and dire consiquences. If someone wants to remove the older version of the library a modified "--upgrade" switch should be used, perhaps "--upgrade-remove-old" or something equally intuitive.
I've been using Linux since the 0.49 days, and UNIX even longer than that, but one of the real problems the *nix community really has is an almost religious unwillingness to accept criticism. This is counter productive and doesn't help any of us (except maybe Redmond).
RPM upgrades as they are currently implimented behave in some non-intuitive and confusing ways. Is it really so difficult to accept a little criticism and improve the semantics, such that even the newer, less experienced users have an easier time coming to grips with it?
The Future of Human Evolution: Autonomy
Try this with DCOM (or it's nom du jour).
:)
COM+ changes everything about component management. It has transaction management and garbage collecting and mostly everything that was in MTS before the merge.
I'll assume you are just badly informed, rather than arrogant.
Right!
___
The ends are ape-chosen, only the means are man's. -- Aldous Huxley
I have been a unix user for a little over 6 months, and I am still discovering the advantages of unix over windows. I cannot count the number of times that I have heard windows users say "unix is a cheap version of windows" the people saying this are those that haven't tried unix. a better effort has to be made to HIGHLIGHT the advantages of unix over windows, in order to draw those users. to windows users their perception is 'why do I want to take the time and effort to learn a whole new os that does what windows can do' my answer is that it doesn't! and they say: 'well, it looks like a cheap version of windows' me: 'enlightenment is not a cheap windows knockoff, its very original' yes, there are some cheapened window managers though. but you have the choice as to whether you want to install them or not. whats that? you don't like windows interface either? too bad! The bottom line is that there needs to be more quality control in the unix world. with new/updated distributions and window managers being thrown up daily, this leaves a bad image and a lot of broken code in the hands of some good unix distros.
Yankees suck. yep you know it.
It's thoroughly off topic, but this occured to me last night and I thought I would post it (now that I have found the key to the Bomb-shelter)
WE'LL RANT AND WE'LL ROAR:
(To the tune of "Spanish Ladies" (many versions) or "Rant And Roar" (Great Blue Sea for example))
By Phrogman (http://www.omphalos.net)
My nickname is "Troll-bait" or "Anonymous Coward",
My comments are leading so you'll have a go,
If you like Linux, I'll be MS-man,
You'll look hard to find me, cause my Karma's so low...
Chorus:
We'll rant and we'll roar like true Slashdot addicts,
We'll foam as we read with our threshold set low,
If its about Linux, we treat it like gospel,
'Cause if Slashdot will post it, we know that its so.
I like to pour hot grits down the front of my blue-jeans,
I'd love to see Natalie frozen like stone,
I don't have the brains to come up with a comment,
I would rather waste bandwidth like a meaningless drone.
(Chorus)
I am a true Slashgeek, my system runs linux,
My software is all GNU, and well-used,
My dreams are in hexcode, C, or assembler,
And I cannot sit still and see Penguin's abused.
(Chorus)
My claim is "First Poster", I don't have a purpose,
Never mind that there's three of us all in a row,
I refresh my browser every 2 seconds,
Just so I get the chance to let you all know.
(Chorus)
Redhat's not Linux, its only a distro,
We'll scream it out loud, till we're blue in the face,
There's Debian, Mandrake, Slackware and Suse,
And many a new one to take their place...
(Chorus)
I am a 5krip7 k1dd14, I am real 1337 now,
I can't do too much hacking 'cause my system is slow
But don't you upset me, or I'll have to show you,
That I can read Bugtraq and then have a go.
(Chorus)
I hate RIAA, I love to use Napster,
It still is the best source for Metallica's songs,
I'd love to buy CDs but I'm a poor student,
So if you ask me, song trading's not wrong.
(Chorus)
Silicon's divine, Transmeta's my Mecca,
Can't wait for my startup to go IPO,
I'm counting the days until we go public,
Now, if we had a product 'twould be an easier go.
(Chorus)
"Meta-moderating" is just fine by me now,
I love to downgrade the things I oppose,
If I think your comments are stupid, say goodbye to your Karma,
I just hope that my actions are never exposed.
(Chorus)
I am an MS-man, my software's not open,
But that doesn't mean my mind's totally closed,
Even though I must reboot every few hours,
I still have the right to think Linux is hosed.
(Chorus)
If an item is high-tech, bizarre or expensive,
I'll let you know that I think in this case,
A Beowulf cluster is surely in order,
Never mind that the cost'd be in outer space.
(Chorus)
My name is Jon Katz, you all love to hate me,
My stories all take a similar line,
I hated my teenage years, so now I'll explain 'em
Cause to me the whole world is post-Columbine.
(Chorus)
My name is Rob Malda, my shorts are asbestos,
My Geek-hobby website has certainly grown,
We got bought by Andover, and now we're employees,
Our impartial viewpoint is probably blown...
(Chorus)
My name is Slashdot, comprising 5 servers,
My Alteon load-balancer's not just for show,
If we post a link to your website, beware now,
When the Slashordes all visit - down it will go.
(Chorus)
"The first time I got drunk, I got married. The second time I bought a chimpanzee, after that I stayed sober" Arian Seid
He has fallen for the biggest myth of today's software industry - the myth that the OS and the user-interface are two sides of the same coin.
They are not and they don't have to be. One size does not fit all. Most users do not want to administer their own systems, they just want the computer to work when they switch it on. Soccer-moms and business executives should not have to understand client-server architecture in order to use their PCs.
When he says "When you develop applications, keep the end user in mind." he is assuming that application development and user interface are so completely and utterly entertwined that the user interface must necessarily mirror the application development paradigm - and so he argues that changing the application development paradigm will simplify things for users. This is utter twaddle.
He then uses this argument for justification of his claim that a 'better way' to write Unix applications would be to use a component architecture built on top of CORBA.
I'm much more inclined to agree with esr, who says
First, get a user-interface design specialist, and a bunch of users, and figure out how they would like to use your application. Then do your coding in whatever suits you/your environment/the application best. Your users will thank you, and your code will be better written.
ai731
--
"I use the words you taught me. If they don't mean anything any more, teach me others. Or let me be silent"
UNIX means several different things. Traditionally, it's an OS kernel with a suite of common utilities. Very handy for some things, like software development and other processes where you can leverage lots of existing tools rather than having to put custom features into every program. It works well, for a certain type of usage.
These days, UNIX--well, Linux--is being viewed an alternative to offerings from Microsoft. To do that properly, what's needed is something else. It's more like Apple's approach to OS/X, in that you start with a kernel for basic services, then you pile a fixed layer of higher-level services on top of that. The whole package, kernel plus libraries plus GUI, is in effect it's own OS. Yes, "OS" isn't the correct term here, but you have to view the result as something that's different from what is normally called a Linux distribution. It's no longer a "choose your own WM, choose your own GUI" set of bricks , but something that has fused into a coherent, independent entity. It's not Linux; it's a system that happens to use the Linux kernel.
Gnome needs this kind of split. If Miguel or RedHat or whoever want to put together a system where everything is fixed and easy to use, then that's the way to go. Trying to spin all of UNIX and Linux in this direction is the wrong way to go. Many people, even myself, might prefer a Gnome-based system, but let's not make the mistake of trying to turn core UNIX into something it was never intended to be.
You know - I had a lot of problem with the point people mentioned: that you needed to have so many libraries loaded just to run a simple program such as gtop, for example; I agree with this. But now I see that is a completely different paradigm than what Miguel sees. That doesn't worry him because he wants those libraries on every distribution. He, probably like the KDE people, assumes that those will be standard on every linux setup. I'm not too sure how I feel about that though.
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.
What?! Microsoft came up with the COM in 1983. Check out their really old research documents.
As for ActiveX, that's just a new name for the same old set of interface definitions that sprung up in OLE and then OLE 2 (read the book "Inside OLE" for the details of the 'migration' between OLE and ActiveX http://msdn.microsoft.com/library/).
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.
Everything he described is provided by OLE, he's copying it. I can't believe you can bash OLE in one breath and then say this in the next. Monikers for object instances, streams for state-refreshing, in-place documents, scriptable components, that's OLE!
___
The ends are ape-chosen, only the means are man's. -- Aldous Huxley
Now with a slight change on the coding style to keep output more consistent (and in XML or something else instead of human-consumed HTML), the components could more easily be of general use.
Additionally, an extra port could be reserved for a local web server on each computer, and it could be used as a name server for components (looked up via standard URLs, eg., "http://localhost/spellchecker"), and viola, CGIs could be used as local components also.
I realize that OLE/Bonobo and so on are better for speedier components that need more constant interaction, but CGIs are easily the way to go for more coarse level interaction. As a proof of concept, just use the world wide web.
- Tom
- Tom
"O, to grace how great a debtor daily I'm constrained to be."
Huh? I didn't even USE the word BeOS in my post! BeOS is entirely irrelevant here. Not to mention the fact that it doesn't even HAVE an object model (yet)
Freedom for developers != Freedom for users to chose. Freedom for users requires that the developers adopt strong standards. All the most user friendly OSs have had strong central policies. By using these strong central policies, apps can interact with each other much better, and "cool" features are opened up. For example, by forcing all developers to use the native toolkit for GUI apps, all BeOS apps are automatically scriptible. By having a standard method for translating foreign file formats, all BeOS applications benifet when new translators are added. Central features are critical and rarely hinder to developer as long as they are well designed. Take Windows. There are 3 different toolkits, native Win32, MFC, and OWL. All use the same backend services, but are simply different programming models. They allow the developer to chose which model they like, yet still allow integratin of apps using the different models. MFC apps are just as integrated into the system as Win32 and OWL apps.
In fact, less developer freedom (to a point) == MORE user freedom. For example, I hate GNOME. It's not religious or anything, it just rubs me the wrong way. However, I'm forced to use it (for some of its apps) or else use KDE and live with two libraries loaded. I could use the KDE versions, but why? If the two used the same backend, I'd have the freedom to choose which desktop environment I wanted without being a slave to the developer who chose to use GTK instead of Qt! Why can't my GNOME and KDE apps communicate well? The best IDE on Linux is KDevelop, and the best graphics software is GIMP. However, they are two different models, so they don't cooperate with each other. Say I like Gnumeric better than KSpread. However, I prefer KWord to AbiWord. Will the two interoperate? No.
UNIX actually had the right idea origninally, but the DEs ruined it. When all apps used the native X protocols, then you could just switch widget sets, and apps would get updated. You could switch window managers, and all apps would still work with each other. What was required simply an extension to the native X protocols. Living with one system object model is surely a good trade for allow the user more flexibility. However, the DE guys thought they were OS designers, and now we have two OSs (incompatible ones) running on top of Linux.
You said MS implements most components in VB. They don't. You said that high level languages like Python should be the basis for a UNIX object model. It shouldn't. And yes, Python is slow. Take a look at some of the Phython based web-browsers.
The 90/10 rule coming from a UNIX guy? The same people who decided it would be a good idea to use a very feature rich, powerful, bloated, network transparent model like CORBA in a desktop object model? I mean you're using some seriously heavy duty stuff just to embed an HTML renderer into your filemanger!
A deep unwavering belief is a sure sign you're missing something...
- Macro viruses in Word and Excel. You can embed Visual Basic code in a Word document that does things you wouldn't want to do in a word processor.
- Javascript and VBScript attachments in E-mail messages. There have been lots of well-publicized exploits here, and even a couple worms that start up by previewing a message.
- Any other sort of E-mail attachment deceptively packaged to look like it's not an executable, when it really is.
Basically, any component-based system should include enough security so the user knows what's going on. Don't make the system so "well-integrated" that it's possible to write destructive executables that run without the user's knowledge or consent.Did you even read the linked article? It describes how pipes, though powerful, aren't the end-all, be-all.
Some claim that this it's a waste of time - now that is a borg mentality if I ever heard one. There is never any reason for a developer to ceace development on a project they like. If anything is a waste of time for *nix, it's whining about GNOME on Slashdot.
Because *nix is the ultimate learning system, there will always be people re-inventing the wheel to see how it works. Because *nix is free it will always be here because it can't be killed by commercial failure. However neither of these are reasons to not see further innovation.
After I've learned command line C programming, I don't want to have to switch to MS to learn component programming. Good luck Miguel, I hope to help the cause some day :)
First of all, to those of you who are criticizing Miguel by saying "Miguel is wrong because being Object Oriented isn't necessary", or "Miguel is wrong because XML isn't necessary", I hope you're keeping this in mind: Miguel's comments can be broken down into two parts("You know, there are two kinds of people in the world..."
1)We should be thinking about ways in which the UNIX philosophy is deficient, rather than continually reassuring ourselves that it's all okay. Look at it pragmatically: Who's got the biggest market penetration? Who's system is easier to learn to program in for the beginner, ignoring cost?
Okay, these are total flamebait questions, so please, please don't respond to these in particular. Use your imagination, and think of some ways in which Windows is better than UNIX, rather than touting all the advantages of your pet operating system. Otherwise, you're just brainwashing yourselves with your own marketing.
The question here isn't which way we should take things, it's how we should think about them. If you want to respond to this half of the question, address what the community should expect of UNIX, not how it should be done.
2)UNIX needs standards, reusability, etc. This is a set of recommendations to the community about where things should go specifically. If you agree to Miguel's motivations in the first part, then read on. His argument is based on looking at "the competition", and I can give you a concrete example.
He mentions IE, and how it's actually made up of a large collection of components rather than being a monolithic application. True. If I want IE's rendering capabilities in my application and I'm using something like Delphi(example because I actually had to do this once), Hell, I'll just draw myself a window and drop the browser component into it. You can argue about whether it's bloated code or not, but the end result is that I didn't have to reinvent the wheel to get something pretty momentous done. Further, I can now focus on doing something with this browser component that hasn't been done before.
For those of you who aren't interested in looking into it, Microsoft is working on something called dotNet. There's a lot of argument about what it all is, and whether it's useful, a product of the devil, etc. The thing that excited me about it is that components from one language can be used in another. And here's where I must admit that I didn't read the details about Bonobo. But my point is that Microsoft is going to have a fully operational Death Star of interoperability between languages pretty danged soon. Miguel rattles off a list of languages:
And this is exactly what isn't going to be the case with dotNet.
I know most of you have lost interest by now, and are happily moderating me down, flaming me, etc., but I have an appeal to those serious programmers and geeks amongst you who bore with me this far. It doesn't matter who came up with it, but isn't that just a bitchin' cool idea???
As you know, everyone who writes about their new features admits that you can already do the same thing in plain old C, but you also know how the rest of it goes.
By now, I've totally lost track of any other points I was going to make, if any. Please fill in the blanks with anything relavent you see:
This is a manual virus. Copy it to your sig and help me spread!
You mean like 'fucknut' instead of 'NMerriam', right?
Well, most people in conversation have different names for me. No one calls me NMerriam, even though that's my "official" name here. My mom calls me Nat. My boss calls me Nathaniel, my girlfriend calls me honey.
The point being that names are for addressing things in a convenient way, hence we do not call "Microsoft Windows with Internet Explorer" by that name, we simply call it Windows. But when MS refers to it, they use the "official" name.
So feel free to call it the "X-Window System", but get over yourself if you think people are going to stop calling it X-Windows just because that isn't the "official" name...
I'm an investigator. I followed a trail there.
Q.Tell me what the trail was.
Recursive: Adj. See Recursive.