Slashdot Mirror
Miguel Says Unix Sucks!
alessio writes: "On the front page of Linux Weekly News there is a report from the Ottawa Linux Symposium where the adorable Miguel de Icaza supposedly states that Unix has been built wrong from the ground up." It's actually a pretty cool interview, and as always, Miguel makes his point without any candy coating! The major point is the lack of reusable code between major applications (a major problem that both KDE and GNOME have been striving to fix for some time now).
Thats not the point the point was that you cannot have two instructions to handle it. And your right a dotfile would have similar problems to that of a database. My issue is that by raising the configuration issue a to whole new level of abstaction you bring forth more problems than you solve.
No, your mom nor your other family members were concerned about "reusable code". They were concerned about what they could do with that computer when they got it home. What they could do with it is largely influenced by the software that can run on that platform
You seem to have missed my sarcastic laden point. My mom and my sisters bought computers to surf the internet and send email etc. When they went shopping for a computer they purchased a PC with MS windows for one reason only... it's the ONLY thing available. And don't tell me about Mac... they were twice as much $$$. Thus my point is that, while MS may be doing some things the right way, that is not why the "averge" person purchases their products. They purchase them because there are no alternatives
Reusable code, centralized libraries, built in driver support, top of the line development packages, and a whole host of other perfectly good reasons brought the developers to Windows. They in turn brought the users.
I respectfully disagree. Yes MS has done a good job of understanding that if you can lock developers into writing code for Windows then they win. This is something that IBM (OS/2) and Apple could have done a much better job of doing. However It's my experience that most developers are actually just regular people who have families to feed and house payments to make. They develop where the jobs are. That has been pretty much MS Windows since the early 90's. I really don't know how much "re-usable code" ( a buzz prase that I'm already sick of), "centralized libraries" or "built in driver support" was going on in 1994, not much I'm guessing. It's also been my experience that *many* MS developers are quite vocal about what a God awfull mess the Win32 API is. Again, the development community develops for MS because there is very little alternative, nor has there been for quite some time. (if you want to develop commercial apps that is)
Yes, MS has done some things right, but lets be a little more realisitc about the way things have happened.
Digital Research. And the particular CP/M port/clone that was bought by Microsoft was QDOS by Seattle Computer.
Contrary to the popular belief, there indeed is no God.
VI is tough, but the interface is perfect for what it was designed for. I know you don't get it, but it was designed such that your hands never leave the home position if you are a touch typist.
I have worked with many Windows developers helping them port software to UNIX, and if we work together long enough, they eventually end up getting the Windows version of VIM to replace Visual/C++'s editor, since it's a much faster tool to work with. (And VIM has the syntax highlighting that they like from VC++'s editor).
For what it's meant to do, speed up coding, it's the perfect tool.
Anyway, the most fun is watching an old-school VI user using a Windows editor. They end up with i's all over their code.
-- Keith Moore
This sig is the express property of someone.
All of these resources are shared by all applications, where possible, to conserve resources. Most of them are very easy to use and many require no coding to setup. For instance, to add retractable drawers to the sides of your windows, you just drag-connect lines from the drawer instance to the window instance, to the view to be contained inside the drawer, and a line from the button/actuator-widget to the drawer instance and boom you are in business. No coding...
Apple certainly has the best reputation for this. All of these details are specified in a UI guidelines document and standard menu configurations are built into InterfaceBuilder. X has a nice built-in software installer. When you install it leaves a receipt you can click on to uninstall or just compress some software.X has a very powerful "Bundle" system (from NeXT). A bundle is a directory containing various subdirctories that contain application resources (binaries, source, headers, documentation, images, sounds, strings to be displayed the user, UI's, etc..). Localizable resources (like string, images, UI's) are kept in seperate directories for the region/language the resources are specific to. The Bundle class automatically fetches the proper localized resource based on the user's localization preferences. The Application itself is a bundle and there are bundles known as "Frameworks" for shared libraries. Frameworks can contain anything (code, headers, source, docs, images, sounds, etc...) and are stored together and are versioned (two or more different versions coexist peacefully: no more problems of a newly installed app installing an incompatible version on top of an existing version).
No API is needed for putting icons into the dock since the user can simply drag the application icon there himself; no having to drag icons into some obscure folder deep inside the system hierarchy.
Oh yeah, it's all running on BSD Unix with a Mach kernel. The sources of which are available here.
So you see, Unix can be made into a modern operating environment for all users, with a consistent user interface, and an API that is a joy to use for developers. However, they didn't build it on X and you'll probably have to buy a Mac to get it for now.
Burris
If you are interested in learning about VMS, I suggest you check out the following: The VMS FAQ and VMS documentation site, which have a plethora of info. There is not much info on VMS available from source besides Compaq, online or off.
The best way to learn about VMS is to get a VMS system. You can get a VAX system on eBay very cheap (sub-$100) and you can get a complete VMS system software for free (see ). The VMS hobbyist page. There's also a VAX emulator which comes with VMS (Charon VAX).
The Unix texts which refer to Unix as a kludged system are "The Cathedral and the Bazaar" by Raymond, and "The Unix Philosophy" by Gancarz, both of which admit that Unix is a rapid-prototyping environment, and that design is not done when programming for the system. Projects like the Hurd and Linux make me yawn because they are just more implementations of Unix. What's the point? If you inist on cloning an existing system, at least clone something interesting!
I agree that it could have been fixed a lot eaiser. There should have been a common API for these things. It follows some of a pattern for Microsoft, which is coming up with something and not thinking through the implications and building safegaurds. Unlike others, I think Microsoft does do some (minor) innovations, but usually just extending other's work in minor ways. Like dynamic linking. They made it pervasive to the OS and easy to use. But they should have realized it would be abused and needed safegaurds like the API thing you suggested. Instead, we have this hack to protect system .dlls in Windows 2000.
---
DO NOT DISTURB THE SE
"Text is MUCH easier than gui, if you know what you're doing"
...etc" is not very helpfull is it ?
But that's exactly the problem ! People new to computers don't know what they are doing, or rather they know what they want to do but have a problem expressing it into precise action that computer will understand. GUI is there to help with that transition.
Having "usage: find [-H |-L
Yes, there is something called configuration. I was talking defaults. In case you didn't know, the start bar in windows isn't always at the bottom either. Fact of the matter is, GNOME puts that bar at the bottom unless you put it somewhere else.
Addlepated - punk & metal
"It was a bug-ridden, crash-prone dog for years and years. "
So was Unix for at least 10 years.
NT is not perfect but it represents something new, perhaps flawed as of now, but promising.
Recall beginning of Unix - how often it was dismissed by mainframe people as a toy that won't fly anywhere ?
oh shit i can't remember if cum takes teh ablative or teh accusative ok bye.
loev,
Axel
mhm23x3, alt.fan.karl-malden.nose
Your concerns would be more substantial if you'd stop confusing (as I've seen you do before) "open source" with "bazaar-style development", and "bazaar-style development" with "bad engineering".
They are each entirely orthagonal. Just as proprietary development, as such, never assures good engineering, neither open-source nor bazaar-style development, specifically, assures bad engineering.
After all, several highly visible open-source projects were developed cathedral-style, and are considered very good in terms of quality (perhaps "category-beaters"): GNU Emacs and GCC come to mind.
I used the "cathedral" approach to develop g77, also to assure quality, even before I understood it as a "cathedral" model, and after I did, I often resisted "bazaar-style" attempts to "improve" it when I felt they didn't, or wouldn't, meet the quality criteria I tried to uphold for it. (Failures being due to my own personal failings, at least mostly, not the fact that g77 was open-sourced! See my GNU Fortran (g95) page for more info.)
Certainly I agree with your implication that much open-source/bazaar-developed software, including some widely celebrated, is developed to a lower standard of engineering quality than should be the case for products of their ilk.
But the fault is not that they're open source, or developed bazaar-style. Those are "features" that allow many more developers to participate, with less up-front investment overall, for better or worse (depending on the quality of the developers, and especially their "developments", e.g. patches, as allowed by the project maintainers).
As far as these three concepts being entirely orthagonal, what I said above is not quite true...
That is, without the public being able to view, modify, and try out the source code for a public software product (whether it's a distribution, like Windows or Linux, or the software running a public web site like slashdot.org or etrade.com), I don't see how anyone can claim their public quality assurance can reach the same high level that it (theoretically) could if it was open-sourced.
Of course, opponents of open-sourcing have long argued that without up-front investments of capital, quality is not affordable.
That may be true, but IMO the more pertinent issue is that only via open-sourcing can everyone determine for themselves whether the up-front investments that have been made have indeed resulted in a product of sufficient quality.
So it often amuses me to see people like yourself essentially (as you appear to do) prefer to blindly trust some corporation to produce quality software on the theory that they had the money to do it, instead of insisting on the product being open-sourced so you don't have to trust it, and can look at the code instead, discuss it with friends, muck around with it to see how robust, extensible, stable, etc. it is, and so on.
Because, in the end, as much as you liked VAX/VMS, in the short time I worked on that type of system, it crashed many more times than Linux has ever crashed on me (about 10 years using Linux versus maybe 3 using VAX/VMS).
And when I found a bug in the Linux kernel (long ago), I reported it and it got fixed very quickly. (Probably because I provided a patch.) I found it only because I happened to be looking through the source code, not because I actually ran into the bug! (It involved fouling up group-protections of files in one place, IIRC.)
But when I ran into a bug in VMS, it took a long time to demonstrate it sufficiently as a bug to my management so I could view the source on microfiche, track it down, and then send it to the Black Hole of DEC. To my knowledge, it was never fixed. (It involved random hangs while doing straightforward, but asynchronous, I/O to normal text files. That got me much better performance on a text-to-PostScript converter I'd written, but I had to back it down to using synch I/O, thanks to the bug.)
Had VMS been open-sourced, not only would I have been more easily able to find and fix that bug and get it out to others...
Whereas those shops that committed to Unix in the early '70s on the basis that it was lean, mean, and came with source code are still able to preserve a substantial portion of that investment by using *BSD and Linux systems, which support a dizzying array of hardware (CPUs and other components), allowing people to pick the hardware that best suits their present needs.
So, open source is not a panacea, neither is bazaar-style development (despite ESR's tendency to write as if it is), but they aren't inherently going to do anything but improve quality over the long run, since quality includes viability of investment in technologies over time as a component.
Practice random senselessness and act kind of beautiful.
I don't think it would be that simple.
:>
I don't mean to sound cynical but geeze two instructions! What happens if I run this program over a network, what is the limit of reg_values I can have, what happens if the reg_value is not there, how do I detect registry corruption, what happens if two people try to access the same keys at the same time, could malicious programs delete values of your registry, could registry information be stolen, etc. Even with reusable code things are still complex.
Speaking about deleting registry values how could I remove values with this two instruction set. Can I allocate space for large registry values.
What would happen if I did this
set_reg_value(user.thisapp.version.property, large_buf[20000]); ?
Is resusable code *really* that great?
In some cases..yes. One of the things that makes Perl great (in my mind) is the huge CPAN archive. If you need to do someting quick and dirty with Perl there is a great chance that there is a module hanging out there which will solve your problem. Course that's not what we are really discussing here, but that's a good example of re-usable code.
Fair enough, but perhaps the idea of 'a whole application-developement framework' is flawed. X provides one of the bottom layers of an application development framework, and is very good in that role.
Imagine saying that ethernet just isn't up to par as a whole network infrastructure. Well of course not, but it's damn good at providing the data link layer and providing services to the more usefull interfaces on top of it.
I agree with a lot of what you say, but I do have some time and some inclination to code... and a lot of experience to offer. But the lack of documentation and planning and the nasty replies that you mention, along with the overly complex build systems the large projects create are daunting. I'd like to code for a week, not spend a week learning how to build something.
Consider that Unix and Open Source development is working like a free market: while there is a lot of variety, and while that causes problems, the benefit is that people do want simpler solutions, but instead of 'staying with' some simpler solution imposed upon them, people choose the best are available (e.g. Red Hat), and run with it, and then so does everyone else, and the bad solutions die.
The interesting comment about people developing Windows Manager skins reflects this: people get fed up with too many window managers, and start to develop skins. Then it becomes possible to have any 'style' window manager, sitting above a 'core' window manager : so then everyone starts to choose the best 'core' window manager. At the end of the day, you have the best solution: an excellent 'core' window manager, and an excellent freedom of different 'styles'.
The free market has decided.
-- Matthew - matthew.gream@pobox.com, http://matthewgream.net
Anyone who wears sandals shouldn't be taken seriously, anyway. What are you worried about?
jack's bicycle is music to my ears
Aah... but if there were not a whole network infrastructure, I *could* probably say the ethernet sucked. X sucks because it tries to be more than it is. Miguel thinks UNIX sucks (and LWN trollishly rephrased him on this - note that LWN is now Tucows!!!) because it doesn't provide the application framework, and as a result fails miserably at providing a rich desktop environment.
Like I said, X is a framebuffer. It's really just an abstraction layer on top of /dev/fb0. There is no application toolkit. You could do something like BeOS on top of X, because then you're just replacing the framebuffer... big deal.
So what's he offering to do? Start "deciding policy" for us? Is this a thinly veiled excuse for heavy-handed GNOMification of existing apps like xscreensaver, rather than the more sensible solution of letting them be visible through GNOME?
No, you miss the point. It's not about Gnome deciding policy. It's about creating libraries and API's to hack against (if you want to, there will always be choice, Miguel or anyone else in the Gnome camp will tell you that) for common tasks such as printing, image manipulation, font rendering, the toolkit, etc. So, by *choice*, if you want, you can use a set of applications that have some commonality.
Miguel is an open admirer of how Microsoft does software development.
Someone please tell me this is a belated April Fools joke!
It's not a joke, but it might not mean what you think it means. I've had the opportunity to talk with Miguel (while waiting for Phantom Menace to start) about his views on software design, and particularly how Microsoft does it. What he admires about Microsoft is there reuse of code through a set of common libraries and their component architecture. Granted if the code is unstable, you're going to have a lot of unstable applications. That's where he doesn't admire Microsoft. So he wants to pick the good things that Microsoft is doing, and improve, by writing stable, quality code. Check out the code to gnumeric some time if you want to see some beautiful code.
----
Celebrate the finer things in life
NT's lineage includes an incredible amount of influence from DEC VMS, sort-of-crossbred with the Mach kernel, but made to work with the DOS/Win3.1 legacy. Is there any wonder that the code's bloated? (like a whale carcass on a desert beach).
I love vegetarians - some of my favorite foods are vegetarians.
I'd reccomend designed API's over evolved ones... I hate to kick UNIX while it is down, but the new QNX/Neutrino system API's are very well designed. You don't know what you are missing until you see them. There are about 30 or so system calls total. For example all timer events are encapsulated in one system call. They have implemented thier POSIX, BSD etc. interfaces as a compatability layer on top of these calls. And I'm sure you are all sick of hearing about message passing microkernels, but doing IPC with one system call that reads like "get these buffers to that process and bring me it's response" is soooo nice.
What I'm wondering is when someone will write a module for Linux that has a really clean, well designed system API like this available. Just because Linux performs UNIX calles doesn't make it a legacy design under the hood. It just supports a legacy system.
One last point: UNIX support is very very good. The existing free software code base is invaluable, and it works just fine as it is. There is no point dumping support for it, considering the limited expense of providing a UNIX system call emulation vs. the thousands of "man" years of work that has gone into it.
-- http://thegirlorthecar.com funny dating game for guys
Many replies here are very uninformed. People should read things to get the basis of what Miguel was saying. He meant to offend you! The better response would be to find out why he did this.
Anyway I agree with him in that we have no reusable components as Microsoft does. GNOME aims to change all of that. I hope they succeed.
He also says that we haven't gotten a Free Software Foundation Operating System for the masses yet. I tend to disagree here. Which masses are we referring to? Programmers LOVE LINUX and BSD. They should.
Uninformed or casual computer users don't.. I don't blame them.. As things are right now I don't believe that Linux belongs on the desktop for office apps. In UNIX "everything is a file" means everything to programmers but next to nothing for a new user. "What do you mean by that?" is the question that would suddenly make your description of Unix to a newbie more technical. I can guarantee you will "lose them" once you begin spouting out meaningless technobabble. That is why its no good. The learning curve is too high..
Of course there is always Applixware and Star Office. Star Office will be GPL'd soon but you have to pay the same amount you would have paid for Win95 when it debuted (upgrade price) for Applixware ($99 USD).
Hopefully this sheds light on what he meant.
Dave Leimbach
Unix, while having no component model, has things going for it that outweigh reuse. The list is ridiculously long but "free" is at the top of my list.
And, surprise, Unix has a component model now -- in fact, two of them. They are called JavaBeans and Enterprise JavaBeans (EJB). One for CORBA is in the works. Bye-bye Microsoft.
Actually he has gone beyond that and is upset about other things I havn't been trubbled by yet. Things that may actually be problems. They are also things he is working on fixing, so I'm content to let him complain. When he is done we will see if he was right.
Yes, that makes things simpler in the windows world (even if the "standard" APIs change every few years, or less). Lack of stability (as in frequent crashes) make it harder. Gain a little, lose a little. Having done very little windows devlopment I don't have a very informed opnion on which is nicer. My little side trip into it felt unplesent, but it may have gotten better if I had stuck with it.
I seem to make quite enough money writing server applications for Unix systems, and the support issues are less of a pain there too.
The "desktop" stuff I do are all hobby projects. Either something I do because I want to see how easy it is to do (like streaming audio over a normal HTTP chanel), or to learn something I can't "afford" to take the risk for in a comercial project (like the STL), or because it just plain looks fun (xtank -- which had it's own threading system).
Also I have a pet thery about desktop tools. The Unix market may be pretty small, but it is also wide open. If I had a new structured drawing program, I might do better trying to sell it into the Unix market where there isn't a market leader rather then going head to head with Visio on Windows. But that is just a thery. I'll stick to server apps. I'm good at it, and they pay well.
I am trying to illustrate that this attitude exists, not saying it's a good thing. Very few users want total flexibility. However, those who do may refer to any limitation of freedom as droolproofing. And, the people creating Open Source and Unix software probably tend more towards providing the user with flexibility than with a simple interface. If this does not change, and if interfaces are not designed to expose a configurable amount of functionality or, failing that, if simple interfaces are not available, home users will not use it. That said, I'm sorry I used the term. There should be simple interfaces. There should also be complex interfaces. I don't object to a simple interface that limits choice, as long as there are as few barriers as possible to using a more flexible interface. Ideally, more flexibility can be exposed in the same interface.
Okay Moderators, I've taken the flame bait. Moderate this down!! Come on!! I've only a got a few Karma points anyway, might as well take them away by cursing your precious Open Source and your damn UNIX!
I hate UNIX. I despise UNIX. I would rather work in DOS than spend another day in X Windows.
The whole platform sucks, although, from what I have heard about Miquel's post, he doesn't explain as well as you might find at Don Hopkins' page (here).
At first I thought that I might like UNIX, heck, I liked DOS back when I used it consistently. Then I actually tried using it. Ha! Using it? More like be used by it. I REINSTALLED THE DAMN THING FOUR OF FIVE TIMES BEFORE I GOT IT EVEN TO REMOTELY RESPOND TO THE HARDWARE!! I found it impossible to get a PS2 mouse working and had to resort to dumb serial mouse! In order to use a peice of software you have to write the equivalent of War in Peace in a bizarre techno-reliogious language that even the Druids wouldn't claim. The software is always IDIOTIC just so the no-life jerk who actually learns how to use every facet of it gets a kick from his superiority complex. Not to mention X Windows: X Windows is the mother of all of these idiot software designs. Not only to have to write the equivalent of War and Peace, but you have to do it backwards with eyes closed! I AM A GEEK, BUT I DON'T NEED IDIOTIC SOFTWARE TO FEEL SMART.
Sheesh... and Slashdot is full of you GPLamers who have GPL shrines in their basements. Seriously, as a Geek who deals with newbies on a continual basis, I wonder whether you GPLamers like building stupid software on purpouse, or is the lack of Sun melts some of your brain when it comes to enjoying the idiotically arcane and inane. I DON'T USE ANY OPEN SOURCE SOFTWARE IN MY DAY-TO-DAY WORK, AND I DON'T PLAN TOO!! I use Windows everyday, and don't see that changing anytime soon.
One these days I'll just create my own Operating System and move to a Private Island and be free of stupid software. I want my software to be SMART. MWUHAHAHAHAHAHAHAHA!!
Besides, I have a life, I don't need to spend useless time tweaking a stupid peice of software just so I can use my damn mouse.
GO AHEAD MODERATORS!! DO YOUR WORST!! I WOULD RATHER THIS POST BE MODERATED DOWN TO THE WORST AREAS OF SLASHDOT's POST HELL THAN TO HAVE IT IGNORED!! I'M TIRED OF ALL THE STUPID UNIX-IS-THE-BEST, OPEN-SOURCE-CAN'T-BE-BEAT POSTS. SLASHDOT NEEDS TO GET ITS HEAD EXAMINED, AND SOME PEOPLE WITH LESS RESPECT FOR THE ALMIGHTY GPL, AND THE HOLY LINUX.
WorldMaker
Within the next few years, Linux will dominate every aspect of computing, because it makes sense. A royalty-free OS that levels the playing field. It would be stupid NOT to adopt it. So WHAT if the desktop is the last thing to fall to us, rather than the first?
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Have to agree with you on this. Although I like GTK+/Gnome and like the look of KDE/Qt ... the reason I got disgusted with Win32 was the unnecessary complexity. It seemed looking at windows that the window manager merely needed to be a thin graphical interface to independent components. Sadly, that is not where Linux desktops are going lately.
... Not a heavy investment in Window Manager internal code.
Of course, there's no reason why someone can't grab the code from GTK+ and do some re-engineering and make their own window manager based on this. Maybe this is why Sawmill is so lightweight
And as you say it would be nice to take some of the natural architecture of Linux/Unix and turn it to our advantage i.e. use of file/devices instead of arcane API calls.
Peter
Bitter and proud of it.
I don't mean to sound hostile to the end user. Droolproofing is highly pejorative, maybe sneezeguard is more appropriate and accurate. Hey, anyone can sneeze, and there's no need to get ticked about it. When it comes down to it, I do get annoyed with low-end end users. But my attitude isn't going to matter at all as long as it doesn't come through in the end product. And what is stupid about having thoughtfully layered complexity in an interface? I don't suggest forcing people to learn how to program in order to make configuration changes. I don't want to have to modify the code in order to get blue buttons. Most people won't, and that will limit the market until better interfaces are available. All I meant to say. I'm rather sorry I didn't word this differently, maybe if I had you would have actually read it.
I gather from the reports that Miguel de Icaza's speech was somewhat reduced in scope from his Usenix presentation.
At Usenix, his talk started from the premise that "the kernel sucks" but only as a springboard to cover extensively the approach, the philosophy really, of moving away from kernel-centric development to a component focus.
Now as a relative old schooler in all this I applaud the notion that every generation needs to overthrow the excesses and cruft of the previous one, so to that extent Miguel's to-the-barricades rhetoric is welcome. Unix, and Linux, have become a sprawling pasted-together mess, which is evident if you compare, say, Aeleen Frisch's first system admin book in 1991 with what there is now.
And some of the principles Microsoft has embraced in software architecture may also be applauded. Although I hasten to add that their implementation of those foundations has broken every conceivable rule of software architecture/engineering, not to mention common sense. Nevertheless, I think Miguel's willingness to learn from good principles wherever they may be found is also welcome.
But where I part ways is with his proposed grand solution space, which basically amounts to: CORBA.
CORBA is yet another sprawling, somewhat incoherent and definitely incomplete attempt to Make the World Behave Like We Say It Should Or We'll Stamp Our Little Feet. I have long felt that the dependence on CORBA, not merely the availability, is a millstone around the neck of both GNOME and KDE.
I've read quite a bit of CORBA and component model advocacy, and it reminds me all too much of IBM-think circa the mid-1980s. "You will use SNA because it's good for you. Here, just implement this spec that comes on four bookshelves of binders."
The brilliance of the UNIX philosophy is scalability built on self-evolving systems, not based on universal frameworks that try to provide order through mapping. As has often been noted, the map is not the territory. And it should not be.
But mapping (metaphorically, if not in its strict technical sense) is what component architectures are all about.
DLL Hell was just the first phase of this. You can argue that DLLs are not "components" by the standard definition, but they are component-like and function in many ways as if they were in such a framework. COM rationalizes and makes DLL World somewhat more orthogonal to the component model, and that is the positive sense that Miguel seems to respond to. I can see some merit to the reuse and iterability inherent in this approach.
But that is entirely a developer-centric approach, and this is where I think Miguel's vision will be sorely tested, and emerge as at best mixed bag: one part fixing some rather sticky issues for GUI development and near-field reusability, one part creating a whole new layer of complexity and frustration for the user, the system planner and the sysadmin.
Components are not static; they evolve, and they evolve both in form and function. In other words, wish as much as you might for a static API for a given component (as Miguel sort of did during his Usenix speech), but it's not gonna happen. Both what the component does and what hooks and appearances it presents to the world are destined -- in fact must -- change over time. That's the lesson we learned as soon as Microsoft put out the first revision to the first DLL.
It is simply impossible to imagine some Component World Authority that has the job of telling every component architect and developer: this is your feature set, this is your quest: go forth (or go C++ or go Java ) and Make It So, and Thus Shall It Always Be! Nuh uh, not gonna happen.
The advantage of reusable libraries as in C compilers is that while some variation in them may be permitted (whether this is a good thing or not is circumstance-dependent), you are basically faced with a binary result: either the code compiles or it doesn't. Once it does, you have a static binary that will continue to work as long as most of the underlying OS stuff remains the same.
In Component World, you are now at the mercy of component dependence every single time you run code. And since the component framework is both (1) more dynamic and (2) more distributed than we are used to with our desktop computers these days, this is going to pose major problems. Some of these have already been noted by the GNOME skeptics who have posted here (including at least one well known GNOME developer).
The problems are inherent in component architecture: compatibility, resilience, security. This is less of an issue when all the components reside in devices connected to one backplane, usually inside one metal box. But with distributed apps and, probably more importantly, mobile apps, this is increasingly going to pose problems.
Remember when you installed some random program in Win 9x and it changed a DLL so that your email didn't work any more? At least you have the ability to reinstall DLLs/programs/the system itself (depending on the severity) to deal with the compatibility problem.
W2K supposedly deals with this by creating its own little mini-World Component Authority backed by an internal database subject to all the usual database reliability and performance issues (plus of course it's closed source). All this does is allow a bigger mess to be made at some point.
But what about this? You're running a nice little cell phone/PIM gadget that is built on GNOME and CORBA, and suddenly you can't get your email any more because some schmucko at a service center upgraded to the latest/spiffiest version of a component your handheld relies on via its mobile link to do its work.
Welcome to Component Hell.
As a non-developer and mere observer of the passing landscape, I would be happy to have someone come along and explain exactly why I am all wet. But for the moment, I am persuaded by Miguel's disdain for the suckiness of the kernel, and completely unpersuaded why components, as instantiated by CORBA and GNOME, are a universal solution rather than a local fix.
-------
Bill Gates Is My Evil Twin.
You can tell it's been a while since I've used windows!! My point still stands, I think. An application should have as it's leftmost and topmost menu something other than "File" -- even if it is just "Options" and "Exit". Don't bother me with details like "Minesweeper doesn't have a File menu". You get my point. But thanks for the correction.
to achieve buy-in from established teams, to prove that using their model was feasible for established products and not just from the ground up, to prove that in switching you could reuse and not reinvent the wheel, blah blah.
regarding your software engineering talents... we agree to disagree ;)
yes, starting with the definition. you are thinking of software architecture, aren't you. :)
i can't speak for miguel, but i doubt highly that he wants the entire microsoft framework for developing applications on linux. maybe at a COM library and up level, but i'm sure he wouldn't wish MFC or the registry on anyone. (MFC is dying out by the way, and i haven't heard the term vbx used since 96, you really aren't up to speed on nt development. and, if you are going to complain about the win32 api, to be fair you will have to lump bare metal calls in X as well, since the win32 includes the GDI.)
regarding your software engineering talents... we agree to disagree ;>
jim
Of course Eunuchs suck. They don't have the equipment to do anything else.
--
Sheesh, evil *and* a jerk. -- Jade
X's network abilities are completely irrelevant to you? Do you work in a network environment? If you are, you are talking nonsense.
city streets are not components in the cannonical sense of the word. But any modern city street is designed much like any other moden city street, albeit with small customizations to help it work the way it needs to
Kind of like "Patterns" in Software Engineering, no?
arvind rulez
Miguel Says Unix Sucks! -- SlashDot News Headline
Now if I posted to SlashDot that Unix Sucks! I would get -1 troll....
Not saying I would knock Unix, though.
"`Ford, you're turning into a penguin. Stop it.'" -THHGTTG
less sucks less more than more. That's why I use more less, and less more.
Another one:
There's a town in MI outside Detroit called Novi. Everyone uses emacs there.
If tits were wings it'd be flying around.
I always hear the Gnome and KDE guys talking about the values of code reuse. As a developer, I must agree. However, the most valuable incarnation of code reuse at this point in Linux GUI development would be between Gnome and Kde. How many things between them have been needlessly duplicated?
Enter the egos. Gnome and KDE will not cooperate with each other, even at the basic levels. If the lack of code reuse is something that really gets Miguel's goat, then perhaps a stronger effort should be made when negotiating with the KDE developers...
Matthew
/. finds me to be 20% Troll, 80% Funny
No, but gedit or gnotepad+ is...i think you want to be comparing vi to msdos's edit command...but then why not pico and msdos's edit?
Because of that standardization, that's why most of the world's commercial software for desktop machines -are- being written for Windows
No, most of the world's commercial desktop software was written for Windows, because *big drum roll here*... most of the world's commercial desktops run Windows!
And that's not because of API standardization, or you would have seen people fleeing in droves at the Win16->Win32 switch which forced everyone to rewrite all their software. Borland's OWL libraries and Microsoft's MFC would have destroyed the Windows programming "community".
That's simply because Microsoft managed to get contracts which put their software on the majority of clone computers, because clone computers, and because Microsoft allowed (some might say forced) network effects to turn that majority into a monopoly.
The problem with Linux above the kernel level is that you can run into a situation of multiple competing API's for most everything, which can become a bit of a programming nightmare.
Bullshit. Name one GUI Linux program you've written. Did you try to write it using two toolkits? If not, then exactly how did the existance of whatever toolkits you didn't use make your life a "nightmare". All it did was give you extra choices to find an API you liked best before you started to program.
Remember, if programmers were forced to use one toolkit, we might be stuck using Xaw, Motif, or even Win32...
Want ease of use? Conduct this little experiment, which i had to do for work purposes a while back... find me the name and length of the longest filename/path on your Windows box. This took me about three minutes in Linux (Unix), mostly waiting on the 'find' command to finish. Bonus points if you can do this in a reasonable amount of time in Windows without resorting to Perl or Unix workalike utility kits. Super extra bonus if you can do it without using a command prompt, but can get an authoritative answer from the gui. And, if you can't do this problem in either Windows or Unix, i'd suggest you aren't a sufficiently skilled computer user to really judge ease of use issues.
As for vi versus Notepad... well, a friend of mine has a good ease of use formula. The proper measure of ease of use is the total time spent doing a task. The formula for this is T(l) + nT(d), where T(l) is the time required to learn a task, T(d) is the time required to perform it, and n is the number of times it is performed. So for tasks you rarely do, T(l) dominates. But for tasks you do often (like, say, the several hours a day i spend in text editors), T(d) dominates.
The essence of this is that while vi is much harder to *learn* than Notepad, it is much more powerful as well, reducing use time. And if you spend several hours a day editing text (like most programmers do), the time to learn a more powerful editor is paid for many times over by the speed gain for complex tasks.
This is why i recommend to friends who use computers daily, even non-programmers, that they take the time to learn Linux. Not because it's more cool or politically correct, but because it's more *productive*. The learning curve in the short term is paid for by productivity in the long term.
And THAT, Young Jedi, is ease of use.
--
Hand me that airplane glue and I'll tell you another story.
We've only ever claimed that it SUCKS LESS.
OOP is hot, COP (component-oriented programming) is getting hot, and OOA/COA (the A is for Architecture) is starting to emit steam heat... so who's going to design an operating system for Intel systems on these principles?
IBM created such an OS in co-operation with Microsoft. It was called OS/2 to fit their PS/2. (Just like OS/400 fits the AS/400 and the OS/390 fits the S390). The gui was completely object oriented. You could even drop an FTP connection on the desktop (or where-ever) and have an integrated and seamless connection to the host. It was very stable, hard to install and hard to maintain. Microsoft took it, combined the UI with win3.1 (IIRC), improved the installation and maintainance and did something about the first point as well. I used it in our office for three years, but had to trade it for NT4. So the ideas are out there, go grab'm, make'm stable, easy to maintain and easy to install and your there. Or are you...
---
---
"Multiple exclamation marks are a sure sign of a sick mind." (Terry Pratchett)
Unix existed when Micros~1 wrote DOS. That's inexcusable in my book.
I want to delete my account but Slashdot doesn't allow it.
UNIX does suck. Everyone from Jamie Zawinski to Rob Pike has said this. The only way you can think it doesn't suck is if your experience is too limited. If, for example, you've only used Linux and Windows, then that classifies as limited experience, just as a programmer who's only familiar with C and C++ has limited experience.
:)
"Suck" in this case, needs clarification. In general, no one says the Linux kernel sucks or classic terminal window mode Linux sucks. The problems have come from trying to use this as a foundation for something more all-encompassing and modern. Is this possible? Sure, but it is difficult. Microsoft and Apple had had the advantage of only trying to support one graphics subsystem, one (admittedly huge) API, and one GUI. Linux developers have to build these layers themselves, and it is hard to keep from stepping on one anothers toes. Gnome and KDE have the same DLL hell as Windows, only they're called "shared libraries" under UNIX
Admitting there's a problem is much better than blind zealotry.
Thank your for introducing some sanity into this debate on code resuse.
Everyone talks about code reuse as if it's the holy grail, and how everyone should reuse the same code because it speeds development and avoids duplication of work. But... actually many times people voluntarily DON'T use existing code on *nix machines, because of the hacker mentality. Look at the window manager blackbox. The author wrote a window manager because he was curious about the subject, and didn't really use much reusable code.
While I'm not partial to GNOME, I'll admit it isn't a Bad Thing, but I think these developers tend to take a very extremeist view of things. Admiring MS's model? Well.. sure.. but they can do it because they are one company, and because they implemented things One Way. This One Way might be a bit easier for mass development, but it also represents a large amount of control. Any windows developer is shackled by code reuse to what MS wants to allow them to do. You may disagree, but if you think about it, MS can basically torque any developer any which way.
I think MFC is proof of this. Essentially, MFC is another layer of abstraction over the win32 api (which.. well the win32api isn't great, but it certainly isn't total cruft), which is designed to be "easier" for "rapid" development of applications. It speeds the development of new applications, but, and here is the important part, ONLY USING EXISTING FEATURES. In MFC it is amazingly difficult to make NEW features. All you can do is recombine old ones.
This is the box MS wants to put you in. The reason that *NIX platfoms, and X, are so cool is that they make innovation easy. UNIX isn't stagnant, lots of new cool ideas, developers, and companies turn to *NIX solutions all the time. Maybe you end up doing work someone else did, but I personally believe that freedom has a small price... and I think a lack of general code reuse, while maybe not a Good Thing, certainly isn't as Bad as Miguel wants to make it out to be.
- Paradox
Man of the C!!!
Slashdot. It's Not For Common Sense
Reusable code isn't everything.
UNIX sucks, but not for the reason he stated, but for the opposite. UNIX was quite good a design from the beginning. Everything is a file. Then people begun to put things like vfs in filebrowsers (Midnight Commander and ftps anyone?), and made various "speed enhancements", like non-file network devicec (eth0 is not /dev/eth0. It is eth0!). Both of that sucks. Because it does not fit in the model. Another thing that sucks is that there is no defined user-level interface for implementing filesystems. And users can not be given ability to mount _any_ filesystem _anywhere_ on the system (as long as they do it without suid). That sucks. Miguel de Icaza sucks beacuse he wants to solve it in The Wrong Way. Look at Gmc. He just wants another Windows. Windows sucks. Macintoch sucks. Ever existing OS sucks for something. We have learned a lot since the 80s, but we are still using concepts developed back then. And even new systems, like BeOS are quite the same. The only better concept in use is the PalmOS, which has orthogonal persistance. But that's all. yes, this is a troll. From Trolltech.
--The knowledge that you are an idiot, is what distinguishes you from one.
--The knowledge that you are an idiot, is what distinguishes you from one.
While it's not what you asked for, there is a steady creeping toward co-operation betweeen the two. Sure, it's inconsistant, and I do agree with Miguel's point about the Unix way as a geek defense mechanism. (On the other hand, competition/evolution has quite a few benifits!)
Gnome and KDE programs can easily run under either desktop (duh! :) ). Gnome's .desktop links have been adopted by KDE 2, so some duplication of effort is being removed there. Also, by standardizing on XML DTDs such as DocBook.
There are other ways that Gnome/KDE overlap, but these are becoming ancient history. For example who's going to remember or care about the old KDE 1.x links after a few months of using KDE 2?
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
So Miguel started the Gnome project because of the licensing problems with KDE/Qt. Good for him. Gnome has some excellent ideas, but they've taken it too far. There's no reason to need a fast machine with 64+ Megs of RAM to support a desktop environment, for crying out loud. Now don't get me wrong, I like Gnome and I use it all the time, but it really is a bloated piece of software. I've even written popular software for Gnome (sorry for the shameless plug :-), but I really think it could have been done much better and require less resources. The only reasons I used Gnome for PowerShell is that I like the look and feel of GTK+ much more than Qt or Motif, and Gnome includes a terminal emulator widget which saved me a lot of work. If there was something else that provided similar functionality (of the stuff people actually use, not all of it) and looked as nice, I'd use that instead. Until then, I'll keep using Gnome, but it looks as though it's heading down the Microsoft path of bloated software with tons of rarely-used features.
And why is it that Miguel is held in such high regard among Slashdot users? He wrote a fairly nice desktop environment. So what? So did the KDE team, but most people can't even name a single person who worked on that project. So he thinks Unix sucks? Good for him. Everybody is entitled to their own opinion, but that doesn't mean that they are right.
</rant>
--
On Windows and the Mac, there is a common printing model. On Unix, there's not; each application must generate postscript itself.
---- ----
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
I think you are getting confused, microsoft are the ones that innovate! And thats what he wants [i guess]... {insert saterical comment here}
Lemure, wtf! Don't you mean Lemur?
OOP really wasn't a phenomena of the era in which UNIX was originally written. They didn't stress it like we do today (and we don't really stress it today). Also, a lot of the code in UNIX is written by a whole mess of other people. The piping features let you reuse entire programs within each other. I really don't think that UNIX is like, the end all to be all of OS's, but it's not assbackwards, it's just kinda cute in ideology, and probably the best thing going at the moment (popularity + functionality wise). At any rate, yeah, he makes some good points, but I can't say that I entirely agree. If you want people to be working out of the same codebase, form a company, or increase communication at the start. Ad Hoc programming and reusable code go together like oil and water.
We're all different.
Eh...
-- Oh Well
Actually, most people do use Red Hat Linux because it has become an "IT manager approved" item due to the fact that you can get it preinstalled on machines from the likes of Dell and IBM.
;-)
Because RH Linux is so widely used, it means that when people think "Linux" the first company they want to get a commercial distribution -is- Red Hat.
Anyway, because of RH Linux's open design, you can run whatever GUI you want on top of it, just as long as it's reasonably standards-compliant. I'm waiting for Eazel "Nautilus" extension to GNOME that Andy Hertzfeld (one of the few people who really has a clue about proper interface design) is working on.
Besides, if you have a Red Hat Certified Engineer (RHCE) certification chances are pretty good that any company that does a lot of work on the Internet will hire you almost on the spot.
Raymond in Mountain View, CA
UNIX is not playing catch-up on journalling file systems. Linux is, but UNIX had them years ago. For example, AIX's JFS.
Compare to Win2000, which has an anemic semi-journaled hack of HPFS which is called NTFS; Mac OS 9 or Windows 98/Me, which doesn't have one yet; and OS/2, which didn't get one until AIX's JFS was ported to it by IBM.
Steven E. Ehrbar
Ah, but the true point is that once the problem has been solved once, the problem is solved forever.
What happens if I run this program over a network, what is the limit of reg_values I can have, what happens if the reg_value is not there, how do I detect registry corruption, what happens if two people try to access the same keys at the same time, could malicious programs delete values of your registry, could registry information be stolen
What makes you think that a database would be worse at handling these issues than a file system?
--
Business. Numbers. Money. People. Computer World.
Yes, but it can't protect the system from being run beyond its rated speed.
--
Microsoft put GUI code into the kernel? Dude are you fucking slow on the uptake? There's no GUI code in the Windows kernel. All the GUI code lies in Explorer and its libraries, not in the kernel you dumbshit. You can very well mess around with the Windows GUI if you're so inclined, grab a copy of lightstep if you don't believe me. The functionality does NOT lie within the OS, damn you're one stupid fucker. An application is only as functional and powerful as a programmer makes it. If a programmer makes it difficult for a user to use a program that is not the fault of the OS. Is it Linux's fault that most people cry when they try to use vi for the first time? You'd cry foul if someone suggested it yet you accuse it on everyone else.
I'm a loner Dottie, a Rebel.
I can't understand how people can be so supportive of something until someone critiques it then they get up in arms as if you insulted their mother. It's fucking computer software you pathetic fuckers. Miguel has an excellent point and a very valid argument. I've seen a few replies that counter Miguels examples and arguments. That is well and good for said programmers and development teams but what about everyone else? Who the fuck cares if the Motif guys have their act together if people can't print or use sound or 3D in their apps. Everyone rallies around modularity and choice but take it to the extreme. If things are broken then fix it, don't defend something that you know is wrong.
Miguel's point about Unix being stagnant is so true yet people never fail to point or some "new and improved" copy of something thats been done before. The best thing to happen to Unix recently was Mac OS X and before that it was probably Beowolf clustering. Instead of calling OS X Macix or something lame like that, they separated themselves from the guys at Bell Labs 30 or so years ago. Apple took a stable and mature kernel and built a user friendly interface on top of it. Apple doesn't force you into a command line or make you edit things by hand using pico or emacs. In OS X all the configuration files are standardized and formatted using XML. Users of OS X don't have to think about what is behind their candy shaped buttons and mp3 files. They press the power button and get to work or play. The open source alternatives take pride in their non-uniformity and command lines. You're not going to take over the world with terminals, you take over the world by making the computer transparent and letting the applications take center stage.
I'm a loner Dottie, a Rebel.
Hey guys, the point is not whether Unix is crap or an excellent piece of code! And in fact Unix, or Linux to be more exact, is damn good. The point is that Linux lacks a component technology. And if you have CORBA on the tip of your tongue, you're either blind or badly misguided. Keep CORBA on the tip of your tongue and take a sip of water to make it slid gently down your esophagus. That in a world where there are no two CORBA ORB's to talk to each other.. And now: Imagine a component technology largely supported, with various implementations on different Unix platforms, each of those implementations TALKING NATURALLY with each other, a s**tload of components implemented on this framework, an operating system like Linux making them interoperate as fast as light... Imagine a powerful IDE coming out with a solid support for an easy implementation of such components... I didn't say COM though, did I? That would be something.. Wouldn't it??
FWIW, for those printing and scanning and photoshopping stuff I use the tools which are best suited for that: Windows. On a pretty fast Celeron.
Now who was trolling more?
Ivo
<grub> Reading
COM/DCOM is a platform dependent binary-level object broker architecture. This only works if you stay in the same environment. So stay with windows and you can do nice things with it.
I wholy agree with you that the underlying micros~1 technology should not be implemented on linux. IMHO, we should implement some CORBA type of ORBs, which allows all kinds of objects to communicate with each other, independent of the OS they run on. What we do not need on *nix is a binary level architecture, but we might need a CORBA style of thing.
---
---
"Multiple exclamation marks are a sure sign of a sick mind." (Terry Pratchett)
to quote Conan O'Brien. Unix sucks! Bad.... Unix Sux! at least halfway witty
Even though you're probably trolling, I'll play along.
.NET's "innovativeness"/success are grey areas, so you shouldn't use either of these in argument - because they are not factual. .NET is vaporware, and Mozilla isn't finished.
Unlike Microsoft, Linux never claims to innovate.
And no, adding some lame extensions to a web browser does NOT count as innovation, especially when Netscape submitted similar extensions to standards bodies before they added them.
Mozilla's success and
Are you telling me you only download source, and inspect the source before installing it?
That's the usual tradeoff. But it's escapeable with hardware support. Consider a system call, where the kernel has access to the stack of the caller, but the reverse isn't true. Pentiums and above support a similar mechanism for several protection rings, so you could, with suitable OS support, have non-kernel things applications could call but couldn't crash.
What you really want is a mechanism which can handle a crash on either side gracefully, just as a CORBA/Java RMI call can. This can be done inefficiently now, more efficiently with good OS support for call-type IPC, and very efficiently with some hardware support. For a while, I was thinking of working on L4/Linux and bringing it up to a usable state, but L4 isn't ready yet. Good ideas, though; it's a must-read for OS designers.
The hardware needed is already in some SPARC CPUs. It's unused, because the Spring OS people went off and did Java, but it's there.
As for getting people to convert to safe languages, I agree with jetson123 that it's desirable, but it's politically hopeless. I wish we were all using a Modula family language. I miss the Modula experience: once it compiles, it often runs correctly the first time. But even Compaq/DEC has shelved Modula.
A good example.
Winamp has a "mini browser" so you can just download and play through that. Nullsoft didn't code a browser... they used the IE object.
I think that is really slick and gecko is a promising start. There is really no reason why we shouldn't standardize on reusable objects. The GNOME/KDE would be a good start.
UNIX does not needs to suffer the same never ending recompiles that GNOME offers.
"You need gnome 404.404.404+4 to compile" - It just came out yesterday...
You can build a biz off that library.. eh?
UNIX does not need to suffer such a narrow minded communist view of the world.
"I will tell you what you need, and you will like it!!!"
Sounds like something I have heard before....
Without UNIX, GNOME would not exist... GO PORT TO Microsoft MFC!
Note, by the way, that the Microsoft style he loves so much, has produced a windows manager which is embedded so deeply in the rest of the operating system that there is no way to have end-user choice, and many windows daemons have to have an invisible window, not for UI purposes, but because it's the only way they can get messages from the OS. The guy responsible for that mess, Bill Gates, has managed much larger and much more successful projects than Miguel, and I don't listen to Bill's opinions about software architecture either.
I agree; but i think the original poster was comparing apples to oranges. vi and edit are both old text screen text editors, whereas notepad is a more modern gui editor. gui are usually much more easier to use by non-techies then their command line counterpart.
Okay, someone correct me if I'm wrong, but I always saw linux as a unix clone.. now okay if Linux is a Unix clone then basically isn't this guy saying that Linux sucks and all Unix LIKE OS's suck? e.g FreeBSD (well all varients of BSD), SCO, and everything else out there that is Unix like sucks, since Linux and all of the mix that has created flame wars out there is pretty much copied from the exact same thing, AT&T Unix.
I maintain that Unix does not suck, but rather that it is beautiful in it's flexability. This bozo claims that it's weakness is "not deciding policy"
Go program for M$, Miguel.
Unix (and for that matter the entire Open Source movement) is about freedom, not about having mission-critical decisions made by some corporate suit who, incidentally, is only interested in making their company more $$.
I repeat, Go program for M$, Miguel.
Miguel claims that a weakness of Unix is in not sharing more code between applications. M$ shares code extensively betwen applications
Miguel obviously has a LOT of trust in M$
that and
Making decisions (good or bad) and taking responsibility for them is part of being an functioning adult. The ability to make decisions is essential. To have the decisions already made and have no control over them is unacceptable. Any competent Unix sysadmin knows that security is his responsibility. A Unix sysadmin who has his boxes repeatedly compromised is likely to be out of a job before too long. When a M$ box gets compromised, it is no great shock, in fact the sysadmin of that box can't be held accountable for a system in which he has no control
I can't believe this idiot sucked me in and made me waste time stating the obvious...
</rant>
"Glory is fleeting, but obscurity is forever." - Napoleon Bonaparte
Miguel mentions that "if you think GNOME sucks it's probably because you are using Red Hat's version". This is just so true.
Why does the default desktop supplied by Red Hat have to be so uggly? The icons on the taskbar aren't event lined up properly for christssakes, but seem to be placed by random. The theme is most boring one possbile, and the settings of the windowmanager is enough drive anyone mad. When you've installed the latest Red Hat you have to spend at least an hour to get the settings somewhat usable. Don't even get me started on the *totally* messed up Netscape fonts. What are people new to Linux going to think! They can't be expected to mess around with fontpaths and fontservers.
The point I'm trying to make is that Red Hat has just slapped the latest version of GNOME available at the time, compiled it straight from its pristine sources and added two links to redhat.com on the desktop. That's just not going to cut it, not this century. If you want to see how a desktop *should* look , straight out of the box, take a look at Helix Code's GNOME version. Now *that* is a good looking and behaving desktop, a desktop I wouldn't be ashamed to show a user who knows nothing about Linux. First impressions are important! If Red Hat has any clue they'll be using Helix's versions from on. They are VAR after all, so how about adding some value to the product! It costs them nothing.
Okay, I'm done ranting now.
Miguel, we already KNOW that UNIX sucks. There's nothing wrong with you saying it but becuase some Slashdot editor worships you it gets posted on the front page of Slashdot that you don't like UNIX. Like we really care!!! Well, I don't like GNOME. So, I'm waiting to see "alehmann thinks that GNOME sucks" on the front page of Slashdot. What's taking so long?
Technical rationalizations (it should have used this architecture! It doesn't support this protocol! The license isn't quite what I want!) are, well, rationalizations. No operating system can patch the programmer's emotions or personality.
And what is X if not a server-based system?
Actually, you've got it backwards with .desktop.
.kdelnk. Take a look .desktop specs - they make reference to the .kdelnk is supported but deprecated :).
.desktop is *actually* just
at the
fact that
If you want to use a program, you can use it with a text-mode viewer, or one scaled down to a small GUI.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
Unix has been successful directly because of its elegance and simplicity. It has needed little innovation for years, and it is most definitely not rotting from the inside out. It is what fresh young minds should learn (and they are, more about that later). Now, continuing with the honesty, NT on the other hand has required much innovation to get where it is technically. It was a bug-ridden, crash-prone dog for years and years. It is only now stable enough to run as a server, and it still does not scale reliably nor can a single server handle many tasks simultaneously. I'm not claiming that there is nothing there: Microsoft does hire a lot of smart people. But they are misdirected once they get there and waste a lot of resources cranking out fat bloated obtuse code whose purpose is to keep the competition down. Unix has its share of petty infighting and bitter debate, but it's about the code, not the monopoly.
So I've never heard anything bad about NeXT except that it didn't come with a color monitor. This may be an often-answered question, but what ever became of the code? Did SJ keep it in a vault and then dust it off for OS X, or has it been published and used since the company disappeared? I know lots of WMs have duplicated the great interface, but what about the internals?
Kill, Tux, kill!
Your little description at the end is all possible and already designed and implemented as part of CORBA.
Unix is good because people can choose their window manager. The whole point is being able to do what you want. If you don't like what's out there then write your own, if you can't write your own then don't complain (or better yet learn how). Code reuse between things like Netscape and Adobe PDF reader would never even be possible becuase the two companies would never share code with each other. On the other hand a stock set of routines to access the printer and such and are the job of things like GNOME and KDE but not the job of X or the kernel. Infact the kernels only job is creating a system to talk to the hardware it's the decision of others what to say. Same with X. X is just a way to get things to the screen, and a damn good one, what you put on the screen is your problem. Just like C is again the chanel for talking but the C I/O lib is what to say.
May your soul reach heaven before the devil realizes you are dead
It's called AtheOS (I'm not sure how advanced it is however).
NT had too bear the backward compatibility burden, so why not directly clone a clean API?
PS: as an aside, I don't believe that for AMD half of the transistor is for backwards compatibility, have you looked at the cache size nowadays?
I'm afraid that the only reason Microsoft has done as well financially is successful is becuase IBM handed them the PC operating system market. If not for that event Microsoft probably would not exist.
It is luck, pure luck, which gave rise to Microsoft.
I don't make the rules. I just make fun of them.
Oh, that's a known bug in SQL 7. No there's no upgrade patch available...
God, how I wish I was one of these guys with the time and brilliance to sit down with the source for a major SQL server program and remove all the bugs.
Every once in awhile I'm stuck in TEDIT on OS/2 when I'm unfortunate enough to be on a machine at work that I haven't dragged in a clone of vi. What a horrible editor it is.
Welcome to planet earth my friend... I hope you enjoy your stay before returning to your home planet... wherever that may be.
Actually I dropped out of the Bermuda Triangle into Philadelphia in 1972, and writing code comes naturally to my people. I could tell you where I'm from, but then I'd have to kill you.
MS has been able to "draw" developers to their platform because they have about 90% (or whatever) marketshare. Developers like to be employed so they can get paid and the such, thus they tend develop for platforms where there are a lot of jobs available
Now yes, but those of us who actually lived through a time when MS was NOT necessarily the only game in town do remember choosing their development tools at least partly based on their own merits, although a lot of that was simply because they could (obviously) track the OS better. I realize this may be a difficult concept for some people to accept, but there it is. They kick ass in the corporate world because a ton of people can fire up VB and blast out an app that looks "professional" to Mr. Marketing Guy. They really do make it easy, and while that's not appreciated in many circles it IS appreciated by anyone just trying to get another job done by the end of the day. Because in the end, THAT is what we developers get paid for.
The revolution will NOT be televised.
it's called plan9
.oO0Oo.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
I was being sarcastic. Yeah, there is a long way to go in compiler technology. Check out the CMU cs dept. They are really pushing the limits on a lot of stuff lately. Especialy their proof checking systems that can verify if code is going to currupt something or not.
bash-2.04$
bash-2.04$yes "Don't you hate dialup connections?"| write USERNAME
You really need to read the Unix Haters Handbook. They have a whole chapter on this, which demonstrates very conclusively that this is NOT the way to do reusable code.
Yes, you can build up big complicated things by piping together commands, and redirecting stuff, and using sed and awk and perl and grep and find and all the rest.
THIS IS A CRAPPY WAY TO WRITE SOFTWARE.
If you change any component, it will break. It will not be portable because every Unix out there has different options for all those commands, and they mean slightly different things. Even worse, there is no error handling. Since all your data is a text stream, dealing with binary data, or heaven help us, actual structured data, (like records, or objects, or whatever your favorite language calls them) is painful or impossible.
You claim "we've got reusable code running out of our ears". Yeah right. I challenge you to build a sophisticated, portable, maintainable application out of that so-called reusable code.
Even worse, there is no excuse for this state of affairs. Before Unix was even invented, there were LispStations. On those machines, instead of text streams, there were functions. Functions with error handling, defined interfaces, and even fancy stuff like introspection.
Unix could have been better.
Nonetheless, I still like Linux better than anything else out there right now... because it has source, it can be improved. The object models that KDE and Gnome are moving toward sound like a great start. They may not be perfect, but hey... what is?
Torrey Hoffman (Azog)
Torrey Hoffman (Azog)
"HTML needs a rant tag" - Alan Cox
Yeah, I noticed that glossing over of the difference between applications that run on text streams like cat, ls, grep and frieds, and those applications that want a little more in the way of plumbing than is provided by a plain old "|".
So, then, presumably if you want change mozilla to use qt graphical componentry instead of gtk (assuming mozilla had a "generic" layer instead of hardwiring one of two competitive but similar GUI toolkits), would it be as easy as changing
toI don't think so. And besides, the sheer number of types of valves and pipefittings that would be required to express the relations for each kind of interaction would proliferate so fast that even a puntuation-hardened Perl programmer would start to weep.
But then I got to thinking (dangerous, I know)- why not just robustify the text stream concept to being 2-way XML with some high level publishing and querying of services that are offered/desired and letting the ends of the pipes (applications, components) negotiate the best fit. Kind of like pipes with glop on the ends?
Loading up the apps and the components with pipe end feelers would surely make then heavier, but at least they would fit more often and more easily than they do now. Some kind of testing and negotiation about what is offered and desired would probably provide some mechanism for resolving things like DLL-hell, too.The idea probably isn't new. I kept thinking of autoconf feature tests :)
Also, while I haven't researched it, some of these ideas must lurk in either Jini or SOAP.
Speed read
"Provided by the management for your protection."
Thanks for the clarification. It seems that the main difference between BeOS and Linux is that lpd is (obviously!) not a microkernel component but instead runs as a system process (daemon). Maybe it's just me, but the 2 methods seem pretty equivalent to me.
True. When I read this:
I couldn't help but think of X. The lousiness of that system is the best example of the problems that come when you avoid policy decisions. And the awful arguments made in X's favor whenever the topic of its suckiness comes up in Slashdot are certainly consistent with the idea that this avoidance of policy decisions is a 'hacker defense system'.Probably the best example of what Miguel is talking about is the difference between what you can do with cut-and-paste in X and what you can do with cut-and-paste in Windows:
But once you move to a graphical environment and thus aquire the ability to effectively represent much more structured data to the user, you need to provide higher-level interfaces to that data. Those text-oriented tools will be pretty much worthless if the file you're dealing with contains a description of a structured drawing. As a result of X's adoption of the Unix approach, all you can really cut-and-paste in X is (surprise!) flat, unstructures text strings.
This pays dividends far beyond cutting and pasting: strong application interoperability means that you can easily access and 'reuse' an existing application's functionality. An example out of my own experiences as a Windows developer, a few years back: I once spent a month working on a project whose goal was to build a graphical scripting tool for a specialized purpose: Users would draw out simple flowcharts, then our tool would generate code from these flowcharts. Rather than build our own flowchart-drawing tool, we were able to use Visio: We designed a set of custom Visio shapes that users could use to draw flowcharts. Then, the development environment we'd built would send users into Visio whenever they wanted to edit charts. When the user was done editing, the development environment would talk to Visio via OLE automation, pull out a highly structured description about the flowchart (basically, a list of all the symbols and their types (including some parameters that the user could specify, such as the conditional expression for a decision symbol), and of the links between symbols) and build a simple C++ representation of the chart that the code generator could then take as input. My job on the project was to build the layer that talked to Visio and built the code generator's input data structure, so I dealt pretty heavily with OLE. It worked out great for us, saving us an enormous amount of development time. And we ended up with a much higher-quality final product - instead of building our own mediocre tool for graphically editing flowcharts (which we would have probably ended up having to do if we were working in unix
I liked Miguel's comments. I'm glad to see that someone is willing to stand up and say that while the emperor may not be completely naked, he should probably put on some pants...
I have a question for you: does evolution always end up with something "better"? Does it move "forward"?
You imply in your post that evolution must exist for something (Unix in this case) to "improve". Improve relative to what? If what someone needs for survival is a better roof and you give them the best possible riding lawnmower, then evolution may have indeed worked to improve the lawnmower - as a lawnmower, but it did nothing for its abilities as a roof.
I hope you get my drift. The point is that there is no such thing as "better", "improve" or "worse" without the context surrounding it. Evolution changes things around, some of them are a better fit for their surroundings and those organisms survive. Nevertheless, the previous mutation that brought success might be the very mutation that causes failure in an unforseeable future context.
This is why I am not so gung-ho as some others I know concerning cybernetics, imbedded computers, etc.. Sure, they would give those with the additions great advantages in our present context, but if our context changed, they could be the first to die off.
© Copyright 2000 Matthew Yeo
For an example of software which doesn't suck, look at VMS.
Unix has libraries (what OS doesn't?), but Miguels point was that the libraries aren't very good. There is no library call to bring up a printing configuration dialog. That's the point. Unix is fragile, and incomplete. Unix's libraries were kludged together and no thought was put into making them good. This is why the OS is in such poor state today, and constantly playing catchup with the more advanced systems, such as VMS.
Linux sucks because it doesn't have office 2000 intergrated?
X sucks because it runs on more than one operating system (and doesn't have office 2000 intergrated)?
And off in another corner I hear, "Gnome sucks because it isn't innovative."
Look, The Linux desktop situation is crazy, but _not_all_machines_need_a_desktop! It's also nice to have machines that don't cease to function when their desktops go down.
Additionally, if we want innovation, we need to have more than one desktop. I'd be nice if the two existing desktops played a little more nicely together.
Miguel's argument is just a rehash of the UNIX haters handbook's view of X. The bit about code reuse is a good point, but it doesn't really make sense that code reuse needs to be tied to a specific desktop environment.
Microsoft has had some decent things done... DLL files and the Registry are wonderful things...
DLL Dynamic Link Libraries is not a Microsoft only concept! Linux uses Dynamically Linked Libraries, they are just not labeled DLL!
Registry The registry is a huge bastard that I would not wish on my worst enemy. Dot files are definitely better to deal with on the user and programmer side. Think about this: the registry is a huge database with all of your configuration data and other data that is really tough to independantly change, and if it goes bad, it can take down your whole setup. Oh yeah I forgot to mention how it is hard to port the registry from windows machine to windows machine and impossible from one OS to another. To make a long story short dot files are portable,in ASCII format, editable, backupable, its an easy to model to program with, it slices, dices, minces, etc!
Microsoft may have some interesting ideas but the registry is definately not a crowning acheivement.
I think UNIX did alot to change the way OS design was viewed. UNIX treats everything as a file. UNIX focused on making a system with multiple users on the same system at the same time.(multiprocessing anyone?)
I think the boys over in Murray Hill are doing alot now with Plan9 and a few other ideas I sometimes hear they kick around.
My question to all of you obviously more experienced coders out there:
What's the next paridigmn for creating the next less sucky OS?
Treat everything as a data object? a module?
I don't know. I would love to see an OS based on a functional programming language. Something small and compact without too much bloat to it. Code up a decent GUI as well. Or how about this...the GUI is the text. Multiple windows of text ala an Xterm, clicking on the word disk0 or some such thing would open up another window showing you the contents of the disk0 object.
Every piece of text is a mouse clickable object. If you type in disk0 it becomes a mouse clickable object which links to the contents of disk0.
Perhaps we would arrive at a new GUI or a new concept that makes either more sense to users, or perhaps is faster to operate with, with minimal learning curve.
A natural language based OS?
A user can type in his questions (eventually speak to the computer ala voice recognition) and receive textual and aural inpouts from the machine. I.E. "Computer, please tell me the contents of disk0." "The contents of disk0 are, foo.txt, bar.c, baz.h"
Eventually somebody or something has to sit down and figure out a different way of looking at the data we are presented and see if it makes more, or less sense than what we currently have.
I don't know who that somebody is but I think it won't kill me to sit down tonight and see if I can come up with a few ideas.
I'm thinking about using a functional language because it forces me to look at things slightly differently than when I write C code.
Anyone else have any ideas or pointers to projects currently looking at stuff like this?
It would be a nice project to jump in to, no?
Dan O'Shea
In 1991 I had two applications that used different versions of the same third-party DLL to make network API calls. One manufacturer stupidly used a pre-release DLL in their code and copied into the local directory, the other used the production DLL stored on the network search path (or on the local drive). The production DLL also had additional function calls.
Many users needed to run both applications. Only answer was to exit windows after running one of them. Then someone installed a Fax driver which also used this .DLL, and one of the applications couldn't run at all.
In the end we ditched one of the applications.
Im glad someone has finally taken the time to point out the truth. Linux is NOT a platform for innovation. Why? Well first off - its based on an OS whose design originated more than 20 years ago.
.NET? Gosh - that idea sounds pretty damn original to me - though Im sure you guys will figure out something to pass it off as yet another "Microsoft ploy to control the world". I'm also almost 100% sure that they stole the idea from some half starving Linux developer who spends his few minutes of freetime after contributing to the absolute purity of the Open Source Movement begging the local populace for a few pennies so that he can feed his poor family.
Now alot of you dont believe Microsoft has made or ever will make any effort to innovate. Those of you that do believe that need to remove those pink tinted glasses that have become eternally attached to your face and finally face the truth of the matter.
Like it or not, your favorite monopoly is innovative. Though whenever they are innovative - the so-called community here on Slashdot is able to twist and turn it into something vile and evil.
Dont believe me?
Everytime Microsoft decides to enhance the functionality of their web browser (which is used by 86% of the internet population) the Linux community whines and complains that Microsoft is simply manipulating publically mandated standards in order to raise the value of their stock options.
The fact is however, Microsoft does own 86% of the market as far as web browsers are concerned (over 98% when it comes to Operating Systems) and in order to keep that position they have to do something that anybody in the Linux community has yet to even dream of doing: INNOVATE.
Look at that sorry POS software you all so lovingly refer to as Mozilla. Thats probably the most dismal failure of the Open Source movement as of yet. (Though I assure you it will not be last) Ever since Internet Explorer 4.0 - Netscape has simply been unable to compare in either featureset, speed, stability, or ease of use.
This brings me to my next point however..... has anybody here heard of Windows
BS.
Over the last five years - Linux has been playing catchup - whether to Microsoft, SCO, or somebody else - it doesnt matter. As of current your favorite penguin sponsered OS is suffering from feature and driver depervation. This will continue to be the case until you people begin to see things as they should rather than as you want them to be.
Remember - Not only does X suck (being one of the most insecure programs on the face of planet earth) - but so does KDE, GNOME, StarOffice, GREP (never did care for that one - who the hell came up with that name anyway - some of those berkley boys must of been toking when they came up with that one)..... need I say more?
Oh and by the way - your flames may be directed to: darkgamorck@home.com
Gam
I love idealists not because I am one, but because they make life bearable for pragmatists such as myself.
Prevent email address forgery. Publish SPF records for y
The best translation I've heard is "It is a poor worksman who blames his tools.", and I am very fond of that phrase. :)
WWJD? JWRTFM!!!
The reason OOP does not deliver some imaged advantage in reuse is that most of the classes built are not well thought out. To build truely reusable classes one has to have the same expertise a good code librarian has. Most programmers have no training in building good libraries with the intent of reuse, so they don't do a good job. The same goes for class reuse, most have not been designed for reuse very well and so they are not reused.
Troy
You just hit it right on the nose.
You can flame Microsoft all you want, but the fact that Windows has a singular WIN32 API drastically simplifies program development and software driver development. Because of that standardization, that's why most of the world's commercial software for desktop machines -are- being written for Windows.
The problem with Linux above the kernel level is that you can run into a situation of multiple competing API's for most everything, which can become a bit of a programming nightmare. That's why people are gravitating towards supporting Red Hat, Caldera, S.u.S.E. and TurboLinux commercial distributions, because at least you'll know what API's to program for with each commercial distribution of Linux. Is it small wonder why Red Hat has become the "de facto" standard for Linux almost everywhere?
Raymond in Mountain View, CA
I'm curious which parts of the GNOME libraries you think are superfluous and should be removed. As a developer, I personally *like* having a bunch of standard libraries available to me. I don't have to worry that the user doesn't have so-and-so library installed; if the user has GNOME installed, they can run my program.
Also, I don't understand your point about the circular dependencies. It seems to me, that in order to be circular, Gtk+ would have to depend on GtkHTML (GNOME dep. on gtk+, GtkHTML dep. on GNOME, gtk+ dep. on GtkHTML.) Well, gtk+ *certainly* doesn't depend on GtkHTML, and GtkHTML should probably jusrt be considered another GNOME stock widget anyway.
OOP is hot, COP (component-oriented programming) is getting hot, and OOA/COA (the A is for Architecture) is starting to emit steam heat... so who's going to design an operating system for Intel systems on these principles?
One of the things that bugs me about all this is the principle of critical mass. Linux got a lot of its critical mass from (1) being based on Unix (2) being taught in colleges (3) being free. Windoze got its critical mass through corporate purchasing departments and sharp (sometimes shark-like) marketing and business tactics. Are the Linux devotees willing to listen and try a new OO-OS concept?
Hmmm... sounds like something someone should be doing in a grad school, somewhere....
I love vegetarians - some of my favorite foods are vegetarians.
Think about how easy life would be if only we could reuse existing components. For example I'll build my life by taking the 'Bill Gates wealth component', the 'Alan Cox programming component', the 'Jean Claude Van Dam appearance component', the 'James Bond suave component', and the 'Sarah Michele Gellar girlfriend component'. Nice life huh?
Of course, if everyone else gets to build their life the same way, it becomes a mediocre life not worth living. If everyone gets to choose to be as wealthy as Bill Gates then everyone is equally poor; prices would sky rocket until a loaf of bread was a billion dollars.
If everyone could program like Alan Cox there would be no demand, or use, for you as a programmer. Why would anyone get you to do the coding when they could get any of 6 billion people to do it?
Unix provides a stable base and a uniform API for applications, good design decisions flourish, bad ones die out.
The problem with the reusable component approach is that it requires bad design decisions to flourish. If there is a poor design decision made in a commonly used component it can't be corrected because of the number of programs it would break if it were changed. Instead of the fittest surviving, the most popular survive. What is worse, there is no basis for comparison and improvement, all programs take on a uniform boring sameness; there is no good or bad to choose from, and learn from. No evolution can take place.
What the component approach does is guarantee that bad design decisions live forever, because no one knows they are bad.
Component programming is like a good looking, but heartless woman; looks great at the start of the relationship, but the marriage is a horrible one.
WWJD? JWRTFM!!!
actually, win2k does do things different. That's why it's so much more stable. You can read about it, search MSDN for the "end of DLL hell" article (I don't have it handy). This protection causes other problems, but solves that one. And it allows a program to put an older DLL in it's app directory and load that if it needs it.
---
DO NOT DISTURB THE SE
I think I've demonstrated here that I know more about Software Engineering than you and Miguel combined. You can't say "everbody keeps rewriting, so we are going to rewrite for the last time!" with any credibility.
And I addressed your misimpressions about DOS in another post.
Case in point, I recently installed Oracle on Slackware. Oracle recommends installing it on RedHat, and has a nice bundling arrangement. I'm sure most corporate Oracle for Linux users will stick with Red Hat. But the fine print reads that all Oracle needs is a recent kernel, compiler, and c library. In practice, it was necessary to add a few symlinks to mimic the Red Hat locations of some basic tools, but other than that is was fully compatible. Oracle uses NOTHING that is unique to RedHat, but they make a point of only supporting that distribution.
My whole decision to run Slackware rather than RedHat was that if I wanted default decisions to be made without my knowledge, and GUI-only configuration, I would have stuck with Windows.
Reusable code is fine, but like someone already mentioned, console-only *nix gives you that. I don't understand why the "Desktop Environment" projects feel it's necessary to re-implement everything with a GUI. Do we really need a GUI to dial into an ISP, when we can just as easily run a script from either xterm or (gee-whiz) a window manager configured root menu or hot-key.
If we're just trying to mimic what Microsoft has done with Windows, we will only look comparatively sloppy and inconsistent. IMHO, the beauty of Unix and Linux is the Unix philosophy. Take how *nix handles email: sendmail is pretty standard, but there are alternatives, and your decision to use one of those doesn't affect who you can communicate with, or which clients the user must use.
I think people should be able to choose their window manager without having that affect what applications they can run. They should be able to choose a between several different browsers, email clients, instant-messaging clients, file managers, terms, menus, etc. The re-use of code should be on the lowest possible level, so that these choices can remain independent. If I am forced to choose between All-GNOME or All-KDE, I would choose neither.
While there are some nice features about components, like anything else it's possible to have too much of a good thing.
. . . .
I believe this is called "DLL Hell" in Windows circles.
You are confusing traditional shared DLLs with components. In MS land, components use COM which supports proper versioning of components - either with multiple components implementing different versions or with a single component implementing backwards compatability.
COM is the foundation of COM+ (which is a marketing term, not a technology as COM is) and the whole platform will evolve into .NET which will allow MS to treat the OS as a comodity when their appeal is concluded and they loose Windows. By then, their platform will be .NET and it will be business as usual.
Meanwhile, Linux has no component model, no distributed transaction services, and no server component runtime. EJB/CORBA isn't nearly as comprehensive as COM+, and isn't real competition. MS is pulling an end run and no one has noticed, yet.
Certainly, there are two ways of using OOP systems (and these can be blended to any degree).
One way is to only reuse the objects which are provided with the system. This is simple and dependable. While this IS reuse, it does not deliver on the OOP promise. Each programmer or group still does each function or task in their own code, while other programmers or groups repeat the same tasks, probably in different ways.
The other way is much more complicated. You have to design an OOP paradigm for the application or system you are implementing and build an extension of the OOP system. It is only when you do this that you reap the major promised benefits of OOP, that your application or system will be reusable and much more easily maintained. Every programmer or group must be committed to the use of the common code base for common tasks. It is more complicated (and political) because everyone must agree in the design stage how everything is to be done. If they are diligent in the design (and, to some extent, lucky) they will produce a system where most objects are reused in many ways. The system is modular, the interfaces are consistent, and changes are highly maintainable as long as the overarching design is adhered to.
I have been involved in both types of OOP projects. Mainly due to politics, I think, the simple but unfulfilling way is much more common.
Interesting viewpoint, considering it's actually their development environment that's responsible for a lot of their success. They've consistently managed to draw developers to their platform, and one of the reasons is they make it ever-easier to produce apps
Welcome to planet earth my friend... I hope you enjoy your stay before returning to your home planet... wherever that may be.
MS has been able to "draw" developers to their platform because they have about 90% (or whatever) marketshare. Developers like to be employed so they can get paid and the such, thus they tend develop for platforms where there are a lot of jobs available.
While your comparison is very nice, it's quite moot. Comparing X to Windows is akin to comparing VNC to Windows. X is a remote display protocol and that's about it. Yes, cut-and-paste and drag-and-drop were added for no real reason, but if you ignore that, all it is is a protocol to display graphics across a network.
Miguel is one of the few Linux developers who actually 'get it'. Quite a contrast to Richard Stallman, the smelly repugnant Uber-nerd who would love to keep Unix a bastion of arcane wizardry, where he is worshipped for providing a free implementation of ls and cp, and a crappy text editor.
I still think that resuability is best achieved using C++ and OO languages.
Unix was a platform for Internet innovation 15 years ago, and Web innovation 8 years ago. What Internet innovations would you be refering to IN THE LAST 5 YEARS? EMACS 21.20030341458587? NcFTP? All of the really cutting edge work (Apache's sub-projects, IPv6, component development models, high end filesystems, etc) are all either being developed as cross-platform projects that UNIX is only one target for, or UNIX (and Linux) are playing catch-up on (e.g. journaling filesystems).
Of course, I would argue that engineering a properly designed system cannot be DONE with open source. The whole premise of open source is not doing design, but hacking code without DOING design. This premise is very well documented by ESR in the Cathedral and the Bazaar and in the Unix Philospohy by Gancarz.
For a prooperly engineered system you need discipline, and you need rigid standards. You don't just hack code together, and if you do you'll just get another system just as bad as Unix. Good engineering is premised on good design, and the bazaar skips this step. Good engineering is a cathedral. It's not a matter of coding, it's a matter of discipline, design, and standards.
writing doc for others... I've thought about doing it, I'm good at it, but it doesn't get a lot of respect from people who don't write it themselves, so screw 'em. It's not like I do nothing instead, I still code, I just do it for more billable hours.
You'll notice that I said Now on the other hand, Unix applications until very recently did not have the cross communication problem that Windows apps had before the line you quoted.
Until very recently (the advent of Linux on the desktop) Unix was primarily used by developers and systems administrators. These are people who's primary tasks can all be solved by either editing text files or piping together applications on the command line. There was and still is no major need for developers and/or sysadmins to be able to embed applications or objects in one another in a GUI.
On the other hand, several end user applications can benefit of being able to embed applications within each other and share data in a uniform manner. That is why I noted that maybe it is time for the paradigm to shift.
PS: Of course there are many pitfalls that have to be avoided such as the library version conflicts (Windows DLL hell) that occur when an app is upgraded and uses more recent components than its the others on the system.
He's not just ranting. He's a true hacker. He's saying Unix Sucks, here's why, and I'm going to try to fix it.
----
Celebrate the finer things in life
I like the fact that I can reuse what I want to reuse. I don't think policy should be involved. You can take any of the GNU code available a use/reuse it. We can reuse it now in many more ways then what he is describing. I don't want someone to say you "MUST" use this component set or that component set. I like the freedom to choose. We remove that freedom, I should just go back to using Microsoft products.
Well when my company presented me with a stock install of Solaris it came with vi and ed. No sign of emacs or pico (which i built for myself).
:)
Certainly it had a couple of graphical editors but quite honestly i'm happier with pico.
However to get gedit or gnotepad to work I suspect they need to be compiled etc... This involves me first finding a copy of sunwspro with which to compile gcc, then using that gcc to attempt to get the open source stuff to compile... but hang on i dont have root access so I have to piss about with paths for ages.
Quite honestly i've never got anything more than about 50k of source to compile properly here. It's a bit demoralising.
At least solaris does have fairly good binary compatibility but then all the binary packages assume you are root.
And with respect to the comment about end users not being able to install win98 - you are wrong.
Considering that a win98 install comprises, putting the cd in, turning on the pc (possibly setting th bios to boot from cd first) then clicking next several hundred times.
You'd be amazed what end users can do when their windows installation crashes before a big deadline. I've even known mothers of my friends to be capable of a reinstall... and that's saying something
I have news for you.
Care to explain why Red Hat Linux has become the de facto standard for Linux? The reason is very simple: IT managers want -standardization-, which drastically reduces support and programming costs.
Because the likes of Dell Computer and IBM are big supporters of Red Hat, the fact that Dell and IBM will provide technical assistance in supporting Red Hat Linux means instant credibility for Red Hat in the corporate world, and it's probably the big reason why Red Hat Linux is the current de facto standard.
Raymond in Mountain View, CA
It drives me nuts when people who are a little bit smarter like Miguel, start to think they are really smart, because while he can see problems, he is still not smart enough to see solutions.
Solutions, huh. You are aware that Miguel de Icaza is working on a little project called GNOME to address his complaints, are you not? What he's doing is explaining his goals by pointing out what he thinks is currently wrong.
I've been thinking about this a lot, lately, and I've come to the conclusion that this really isn't true anymore. The Bazaar's been bought out, leveled, and turned into a strip mall.
For example, here we already have two groups (GNOME, KDE) whose architectures, approaches, and hidden assumptions are basically entrenched in the marketplace. The "community" has already decided that we shall use CORBA (with all that entails). It's already been decided that we're going to use the same basic windows/mac/amiga hybrid interface (look and feel between KDE and GNOME are basically the same IMO). Other window managers are begrudgingly supported, but each environment has a definite pressure towards the One True Window Manager. It's already been decided that the ideal free office suite is essentially going to be a pale copy of Microso~1's suite... I could go on but you get the point.
Honestly, I'd love to help change this, but think about it. If a third team came from out of nowhere and proposed/implemented a simpler component architecture that wasnt so tied to one GUI (or tied to a GUI at all -- GUIs should be wrappers, not core software), or tied to one huge set of libraries, that didnt require developers to buy into one overarching desktop environment... or that wasnt subsidized by RedHat, TrollTech or Corel for that matter... what do you think would happen? It would go undernourished and die a slow whimpering death, amid cries of "but we already have one component architecture too many!"... assuming that anyone noticed it at all.
There's no point, anymore. It's actually become a very repressive and stifling environment. It's the 1980s all over again.
Hmmm... does Miguel have the courage to take a step towards consolidation?
To hell with consolidation. Some of us still believe that UNIX is about innovation, diversity, and beautiful, sweet, ubiquitous chaos. >}:)
HUGE DEAL
/dev/fb0 which gives you NETWORK TRANSPARENCY. When you write an application on X it can display on any X server.
/dev/fb0. And Xlib is signifigantly more complex then /dev/fd0 anyway. X performs over a network. Compare that to VNC which is much closer to being just a frambuffer.
It provides a level of abstraction on top of
It may not be perfect, and it may not be fast, but it's a lot more then you make it out to be.
It's a much better platform the target an app kit to then
Better to have many thin layers of abstraction implementing standardized interfaces then one BIG standard API to do everything. This is what we've learned from n years of software engineering.
Unix's biggest design blunder was having a different implementation language from the shell language. Things like "cat", "grep", and "cut" are very loosely coupled with your program if you call it from them. A much more advanced, well designed system, is the Lisp Machines, were Lisp is used everywhere. All of the components were written in Lisp, your shell is Lisp, and you call everything with Lisp. In Unix, you write your programs in C, but you call programs through this awkward, fragile interface which provides you with no feedback while the program is running, no meaningful results except an 8 bit status code, opr if you're really lucky a one way text stream. Unix is primitive and fragile. All of those text utilities are not objects which can be called. On much more advanced operating systems, BETTER components are already available, with better interfaces. Those text utilities do not come close to what the more advanced, more stable, and more reliable, systems provide out of the box.
The most exciting thing about the Unix philosopy is the way small components can be strung together (with scripts and pipes) to easily create complex applications. What if this design goal could be moved out of the realm of the command line, and directly into the world of the GUI. If, as Miguel states, the large Linux apps can't reuse code, they don't have to follow the Microsoft solution of DLLs (and the version control problems they create), we already have the mechanism in place. We just need to be true to the Unix redirection standards in the design of the larger components. With visual tools to expose the larger app's components to wiring, relatively novice users could discover the power of scripting. For example, the output of a spell checker component could be wired to a insertion point in text. Or an entire spreadsheet could be inserted into a document, using standard text and XML formatting.
OK. Apparently I didn't make myself clear - it provides no more application-building functionality then a raw framebuffer. Xt, an addon, provides a basic widget set, which is one piece of the puzzle. Network Transparency is nice, but it hardly qualifies X to be a whole application-development framework.
Horses have been around long before cars, but when was the last time you rode one to work? Since when was antiquity a basis for quality? (well, besides in wine...)
It's called COM. Take DirectX. Now in its 8th major revision, the library has almost been rewritten, but still maintains backwards compatibility without sacrificing size and speed. The problem with UNIX, though, is not that. Its the numerous, incompatible libraries that do the same thing.
A deep unwavering belief is a sure sign you're missing something...
If you don't like his vision, first, you can try to help through input. If that doesn't work you can use or make something else. If that doesn't work you can do nothing while you whine and troll. What a wonderful world.
MacOS X as a great example of what Unix can become if it's done right. This is true
Lessee how Apple is making Unix acceptable to the masses:
+ Dumped the text config file system in favor of an XML-based system and the NetInfo registry.
+ Built a file browser that lies to the user about the actual layout of the file system.
+ Doesn't include a terminal emulator, so all software will be 100% GUI.
+ Ignored the last 15 years of UNIX APIs, specifically anything that relates to the UNIX GUI system, instead uses three homegrown API sets.
Sure deep down inside, MacOS X is a Unix. But it's probably easier just to think of it as a Mac that runs Apache.
--
Business. Numbers. Money. People. Computer World.
Obligitory
The suckiness or non-suckiness of UNIX all depends on what you're using for. Given that Miguel comes from GNOME, inherently a desktop project, it is understandable that he isn't to fond of UNIX, because for those tasks, it DOES suck. The problems he pointed out have long ago been addressed by COM, OLE, OpenDOC, etc. on other platforms. The desktop user and the traditional UNIX user are inherently quite different. Desktop users often use a series of different appliactions, all upgraged often, and all interoperating with each other. Desktop OSs, like Windows and Mac, and OS/2, were designed with these needs in mind. However, UNIX was designed for a radically different purpose. Lets look at the design environment of UNIX. It was used originally at the Bell labs think tank, where people used it to work on their own projects. These people didn't have a spate of appliactions to work with, they used UNIX as a standard platform for their own projects. Thus the high degree of flexibility and personal "sculptability" that UNIX enjoys. Later, UNIX found use in custom solutions such as in AT&T's network. Further still, people designing back-end servers found that the fact that UNIX ran a single application (or a tightly interwound team of applications) well for months on end made it perfect for server tasks. The "traditional" uses of UNIX all have this in comment. However, as I already stated, desktop uses are quite different. These days you have games, word processors, web-browsers, art programs, audio programs, etc, that are all used on the same system, and all have to share resources. In the traditional UNIX environment, you could get away with the multitude of libraries that the applications needed, because you were often running one fixed set of applications. However, that same method applied to the desktop user reeks havoc. This is why I complain that I have dozens of libraries on my system. Along with two glibc and libstdc++s, I have two Qts,and KDEs, one gtk+ and gnome-libs, tcl, tk, and numerous other support libraries. Problematically, I have to use them all AT THE SAME TIME. My audio programs use TK, I use KDE2, but KDevelop uses KDE1, and GIMP uses GTK. In the traditional UNIX environment that was fine. You used the machine for software devel, and you ran only one set of libs, because your apps didn't need other ones. So, UNIX does suck in ways. Though the Linux community has done an admirable job making it competitive with Windows, the design is still flawed (for desktop use.) The sheer bloat of the software is the only clue you need. What should be quite a thin, light system (after all, Linux is a fairly selvte kernel) becomes a system nearly as bloated as Win2K! However, that's just a side effect of trying to shoe-horn UNIX into something it wasn't designed to do. That said, UNIX doesn't suck. BeOS couldn't server my little brother's web-page, but that doesn't mean it doesn't suck. It simply wasn't designed to do that.
A deep unwavering belief is a sure sign you're missing something...
but less is more!
miguel works in the (graphical) application framework area of linux - how applications are built, the resources they share, the services they expect from a window manager.
since there is no 'standard' for the application services that window managers provide, new end user applications often have to each rewrite this code because they cannot count on it being provided in a logical, consistent manner.
the problem is not in what miguel is saying. it is that you don't understand the context.
without a this framework in place the effort required to create linux applications is sub-optimal.
jim
ps. you really have no idea what you are talking about with DOS, NT, or software engineering.
Notepad has almost the same menu structure and shortcut keys as MS-DOS editor.
You need to reach back to EDLIN if you want a crofty old MSDOS/PCDOS editor that's completely different from Notepad.
So Miguel is basically stating that the answer to promoting innovation on the *nix platform is high-level, reusable components? I'm still vague on how this is going to revolutionize our beloved platform and spur innovation?
I find it rediculous how much code overlap there is because people want to force their socio-political agenda on us through the use of the GPL. Us Apache and Mozilla people are sick of not being able to reuse code with GPL applications!
IF YOU HAVE A PROGRAM WITH LIBRARY TYPE CAPABILITIES, PUT IT UNDER THE LGPL!
uuuuhhhhhnuunnnnn, sure, but can I still be janitor?
When someone yells "Stop" or goes limp, or taps out, the fight is over.
I've been running NT4 for over a year now on my dual celeron and its NEVER blue screened because of the OS. When I was doing some overclocking it locked up and when adaptec cd creator killed winoncd it blue screened. Other than that its been perfectly stable. Sure apps crash occasionally and netscape with the usual segfault but its never caused by the OS.
Only the State obtains its revenue by coercion. - Murray Rothbard
Perhaps he would have some useful insight on how to build it correctly. It's certainly even for anyone to say it was done wrong, but I dont see many people showing much progress in doing it right. Hey, it works, it's not M$, good enough for me!
--C:\DOS C:\DOS\RUN RUN\DOS\RUN
Yes; it's amazing what appeals to people when they are being paid.
I don't make the rules. I just make fun of them.
X is much more that just a "framebuffer". Remember that X has network transparency built-in, something that BeOS doesn't have. X also has had years and years for applications to be written for it.
I don't know enough about BeOS architecture to speakw ith authority, but something doesn't quite seem to jive with your "server-based model" comments. It seemed to me that BeOS used separate server processes to provide system services (like the GUI and printing, your 2 examples). Guess what? Under UNIX, X and printing both are server processes as well! Could you clarify the distinction you are making? At first glance, it doesn't sound very valid...
Yeah, aside from shared libraries, there's no reuse of code. snicker
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
Hmm, sounds like JavaBeans.
Ewige Blumenkraft.
I think that OOP does encourage more reuse. I think that the practices of programmers are what limit the amount of reuse. The need to position onesself corporately or a sort of competition between programmers (Look, I wrote more code) between programmers. Most universities these days teach programmers to look objectively at such situations in the courses that emphasize the management aspects of software engineering. Traditional methods of payment emphasize work done, but by what metric do you measure the work done in a program. If you reuse someone else's code, by traditional practices, you get paid less. We learned years ago that paying for every bug found and fixed was a bad idea, people programmed bugs in on purpose, so that later they could find them and be paid. If you take these factors out, OOP DOES encourage more reuse, history has taught us this.
We're all different.
Eh...
Isn't this akin to saying that, in the modern era of 747s and stealth aircraft, the Wright Brothers' Flyer apparently was built wrong from the ground up?
"How many light bulbs does it take to change a person?" --BMcC-->
Another point I see people making is that they think that Miguel is trying to force users to use Gnome. That somehow what he is saying is that he wants to dictate policy for you. Goodness! That's not what he's saying. He sees it as a weakness that Unix doesn't have some commonality in terms of a component architecture, font rendering, printing, toolkit, etc. The Gnome Project aims to give developers who choose to do so a set of libraries and API's to hack with that provide commonality. It gives opportuntiy for further freedom, not less!
----
Celebrate the finer things in life
Microsoft was working on and selling Xenix (now SCO) in-house in the early days of DOS. Furthermore, Multiplan and Word were developed cross platform on a PDP-11 running unix.
Yes, the guy who originally wrote DOS did model it after CP/M (which was modelled after Digital's RT11 or RSX11), but when Microsoft got hold of it they set about adding subdirectories and IO redirection a la the Unix that everyone at Microsoft was using every day.
First he publicly flogs his SO for using a Mac, and now...
the adorable Miguel de Icaza
What's up with that? I've called other men Handsome, eg. Tom Selleck, but never adorable.
--
then it comes to be that the soothing light at the end of your tunnel is just a freight train coming your way
then it comes to be that the soothing light at the end of your tunnel is just a freight train coming your way
I agree with both of your sentiments; however, since you can code but choose not to on account of lack of documentation, why don't you be the one to generate that documentation for other programmers? I know that reading through code sucks. I hate taking up someone's old project and having to read through their code. But, if we want to push forward, someone needs to do the dirty-work. The problem is, we expect the person who coded it to also document it. While that may be the easiest because they understand the code, we, as users who know how to code and read code, can offer something more than just being leeches on the skin of those with the initiative to provide us with software.
Jeremy
I have read it, and, IMO, it's totally the wrong approach.
IMO, MS should have implemented a 'install shared file' API a _long_ time ago (like, when Win 3.x was out) when these problems started to become apparent.
The article lists 3 kinds of problems that give you dll hell.
1) Rogue programs overwriting new dlls with older ones.
2) Badly written programs rely on undocumented side-effects or hidden data members that dissappear with new versions.
3) New dlls introduce new bugs.
3 is written off as being minor and unimportant, and for the most part I agree. Any new software can be buggy, and if it is, it should just be patched with an even newer version. This would happen if a new program used a new buggy static library, and so isn't really a dll-only issue.
2 is called the most common cause of dll hell & touted as being the most important reason to change. I say, fuck 'em. If people write programs that rely on undocumented implementation details, as opposed to a published API, then they deserve to have their shit break on them. If you've got a program that breaks when this happens, then give lots of shit to the people that wrote a crappy app, and a patch for that; don't blame the dll writers for changing stuff they never agreed would remain static.
1 is the biggest problem IMO. And it's been around since Win 3.x because updating shared dlls is a pain in the ass. There is no standard way of overwriting shared dlls. If MS has just put in another couple of API calls to install dlls for you, that did all the version checking for you, and set up the auto-copy-on-restart for files in use (that is different for every platform, and a pain to code the first time. I have standard functions for doing this now), and _never_ copied an older file over a newer one, then that would have solved so many problems. By putting auto-version numbering on by default in all their IDEs, this could have been so simple.
I still can't believe that InstallSheild 5.5's default setting for installing files is to overwrite an existing file, whatever the version/date of the original compared to the new one is. That's just sloppy. And if you don't go and check _every_ _single_ file group, and switch them all over to "install only if newer version", then its easy to start overwriting stuff by accident. Yes, it's sloppy not to check it all yourself, I know. But it would be nice to have sensible defaults on the thing.
Why doesn't the gene pool have a life guard?
That's the original goal of many -most- of our projects. To date, however, every single piece of software written *does* suck, in some way or another.
.DLLs, making everything (supposedly) reusable. What happens there? Hell breaks loose, every time you install a program which relies upon a newer/older DLL, your whole system crumbles down gradually... I think "Enthropy 2000" would be a more correct name for W2K.
Unix gives some provision for reusable code - libraries, for example... Of course, Unix was designed over 30 years ago, and the issue was really not important... But well, today we have a great deal of programs which *do* implement ways of reusable code... Very successfully, IMHO.
Windows, OTOH, was built around the
I love Linux for its flexibility. Drop the kernel in and everything else is optional. Want the standard UNIX utilities? Add 'em. It's optional. It's all optional. No one dictates that policy. That means I can install Linux on my embedded device and leave off 98% of the crap you get in a standard distribution, hack some sort of GUI out. GGI or X on GGI or X on custom hardware. It doesn't care. No one set a policy dictating things. But wait! I don't want a window manager on my embedded hardware! NO PROBLEM! I can make my own UI!
Griping about the flexibility that makes the system great is stupid. Remember the Chinese guy from UHF? Lets all face Miguel and say it together "STOOOOPID! YOU SO STOOOOPID!"
Tongue firmly in cheek, of course.
Anyway, now that we've got that out of our systems, the point about component programming is valid. The text tools are designed to be simple and flexible, but the GUI is a relatively new add-on and is in some ways more primative than Windows 3.1. I've complained about the lack of a decent print subsystem myself. And GUI apps tend to try to do more than the simple text based ones. I think many people view X as nothing more than a way to keep 10 or 15 text terminals in view at once.
Thing is, this is all going to get fixed. Several companies are working on the printing problem. Once they all screw it up and present 15 different conflicting standards, some group of free programmers will get pissed off enough to write one from scratch. X could go away as well. Much of the new software is GTK based, and porting GTK should be as easy as porting GDK and a bit of other stuff. ORBit doesn't rely on X, and most of the Gnome stuff builds on GTK.
UNIX may suck, but unlike the competition, UNIX is going to get better.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
You want to take a look at GNUstep. It's part of the GNU project, and is an effort to recreate the OpenStep environment entirely as free software.
Many M$ apps don't even use the DLL's like they are supposed to. They statically link them. Third-party vendors tend to Do The Right Thing, and dynamically link to the DLL's, and get bit.
M$, on the other hand, statically links the DLL's that many of their apps use.
So they get code reuse, but they don't reuse binaries at all. At least in *NIX, the C libraries are all dynamically linked. Just think about the bloat we would have if they were always statically linked instead. *shudder*
NeXT shipped color in 1990. The codebase was alive as long as the company was alive: right up until it was sold to Apple for US$450 million, and then it continued to live as MacOSX.
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
Why not email me and find out.
Thad
Thad
Having concept of Window Managers is not bad. The problem here is that Xlib interface for interacting between apps and WM is sorely lacking.
As a developer I refuse to link my applications with GNOME because it has taken a few good concepts and gone WAY overboard.
Tell me about it. I triend compiling the latest and greatest sawfish the other day and couldn't because it looked for all these gnome libs! Bye bye!
What we need to overcome those limitations are well-thought-out and documented ways of handling structured data. A *nix version of Visio, for instance, could spew all the information you need about the diagram as a text stream and, as long as the format and structure of that stream are documented, you would have all the functionality that OLE provides.
Sure. But for that to work, I have to write code that parses whatever data format Visio provides. With OLE, I just made some function calls to get the information I needed. Why make Visio to 'compile' the data structures representing drawing down to some stream of bytes, and make me write code to rebuild my own version of the structure from that stream, when (with the right API), I can just talk to Visio and query the structure it's storing internally?
Of course, Visio could provide a library that I could link to for parsing its output. But why do it that way, when the component model offered by Windows is powerful enough to do what I needed in the case I described, and also allows applications to do useful stuff like embedding and displaying arbitrary objects from other applications?
- Text-file based system administration has to go A good idea at the time; a lousy idea today. Early UNIX had only
/etc/passwd. Today, there are dozens to hundreds of text configuration files. Converting them to XML isn't a fix. The OS needs a database: fast-read, slow-write, and very reliable. NT added the Registry, which was a good idea misused. This area still needs a major rethink. It's not glamorous, but it's the cause of most UNIX trouble. - A program is not just a file. The MacOS has the most coherent idea of what an application is: it's an executable file with attached resources placed anywhere, plus a set of preferences in a document in the system preferences directory. Deleting the preferences document is always permissable, and returns the application to its newly-installed state. This model gets rid of most of the need for installers, uninstallers, and similar crap. (The MacOS has other conflict problems, but they stem from the fact that down at the bottom, the MacOS is basically built like DOS.) This is much better than the UNIX or Windows models, which involves pathnames, registry variables, little text files, and various other crap.
- UNIX interprocess communication sucks. In the beginning, there were pipes and signals. Trying to do anything complicated with just those, and getting the error cases right, was next to impossible. A few generations of hacks later, it's possible, but still hard. The basic problem is that what you want is a subroutine call, but what you get is an I/O operation. Trying to build CORBA, COM, OpenRPC, etc. on top of UNIX pipes or sockets is slow. Interprocess subroutine calls need to be designed in as a basic primitive. Take a look at L4 or QNX.
- Naming is basic. Operating systems have lots of named objects, but they aren't always in the same name system. This is the current struggle in OS design, with Microsoft pushing various "active directory" concepts. Think of directories as being independent of the file system; UNIX lets you put devices in directories. Arbitrary objects (CORBA, sockets, maybe even URLs) should be placeable in the name system. And security should be built around this.
- Somebody has to be responsible for security And it ought to be the OS. UNIX has far too much trusted code. (So does MS Windows. The MacOS doesn't even have a security model.) Go look at Multics to see it done right.
If you get these things fixed, the upper layers can be much less messy. But so much has to be changed to fix this that it's a big job.On the other hand, the open source community has the advantage that any one group can lay its hands on all the source. So if some group undertook to clean up Linux and produce "Linux 2", they could do so.
This is probably the most intelligent comment I've read in this whole discussion. As far as the window manager running as root, that wouldn't even be necessary-- the X server already has to run as root, why can't it just chown /dev/gui to the user that started it, then let the user processes like the window manager create and delete things in there as needed? Then allowing other users access to given windows is as simple as a chmod on /dev/gui/win42 or what have you. Subwindows could be dealt with by having /dev/gui/win42 actually being a directory with as many named pipes as needed to do what we need to do, and subwindows being a window directory inside that one. Borrow the NeXT philosophy where a directory can be seen as an object in and of itself, but still also seen as a directory when needed.
Anyone? Bueller?
---
At least mafia-owned pizzarias make excellent pizza. Compare to Bill Gates.
Most of us use linux not because of technical or moral reasons but because we like the interface better.
:) I don't mean this in a flaming way at all; I just didn't think I'd ever see someone stand up and proclaim Linux to be wonderful based on the user interfaces available for it.
This is simply not true. Linux interfaces have been awful, oh so unimaginably awful, until recently. Now they've moved up to mediocre
Windows standardized their interface and thus restricts the user.
This is a myth, or at least we have yet to see any evidence to the contrary. Linux provides a broad, empty canvas for interface designers, yet we haven't seen anything innovative or especially slick from a usability standpoint.
I am very afraid that this flexability which linux posseses will be deystroyed by gnome/KDE. As these projects progress more and more programs which could have been implemented on the command line are implemented in gtk. Soon I won't be able to access my settings except by dialog boxes and I will once again be trapped in windows hell.
This is a classic overreaction. If you have access to a terminal window--heck, even OS X on the Mac will have this, though it won't be advertised to the general public--then you can do whatever you want.
I agree, though, in that KDE and Gnome are generally poor interfaces to standardize upon. It's not at all clear why one would choose a Linux/X/Gnome combination over, say, Windows 2000 or NT. The Linux kernel is cleaner and more stable, yes, but that doesn't matter when you put millions of lines of code on top of it. Instead of the kernel crashing, part of Gnome crashes. Better? Yes, but not something to get excited about. Perhaps what is needed here is a simpler GUI that would be a better base standard than X and a minimalist window manager.
A standardized interface means several things. It means no competition which stagnates development.
Linux GUI development is already stagnant. Years and years are spent in an effort to get the same functionality as crusty old Windows. I wouldn't be at all surprised if Microsoft, who can certainly afford to pay respected experts what they deserve, manage to move GUIs to the next level before any open source project does.
He's allowed to have his own opinion, and I'm sure what he's saying is correct... but he should have mentioned that about 25 or 30 years ago... its a little late now.
NT isn't *nix. NT is secure (!?) Windows. NT may models itself on *nix but it doesn't quite get there, does it?
© Copyright 2000 Matthew Yeo
"The major point is the lack of reusable code between major applications..."
I agree that this can be a problem if you are writing a "major application" under Unix. You constantly come across problems where you think "surely this has been solved before".
And GNOME is doing an admirable job of solving some of this problems in libraries--unfortunately they still are global solutions. You have to buy into GNOME to an unacceptable degree to get the solutions to work. For instance, you have to use GTK, CORBA, etc, etc, etc.
--
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
GNOME wants to innovate, that's why they copied OLE to design Bonobo.....
GtkHTML is a GNOME widget. It does not depend on GNOME, it will be (is?) part of it.
:)
If you feel you have to slam the GNOME developers because they dared to give a UI widget a MISLEADING NAME, that's your issue.
Give me a break!! Apache was started and is primarily developed on *NIX boxen. IPv6 a standard that was first implemented on a *NIX box as part of the reference implementation for the IETF.
Linux maybe playing catch up for journaling file systems, but not *NIX as a whole. Does NT even have a journaling file system??? I think not.
You know very little about the reality of the developement of the technologies you mention.
Troy
Wait a minute here. I remember this thread on gnome-list. (please see: http://mail.gnome.org/pipermail/gnome-list/2000-Ju ne/039883.html)
I'm going out on a limb here. The reason (in my opinion) that some of the widgets are in gnome as opposed to GTK is that GTK widgets did not enforce policy. The GNOME abstraction on top GTK widget set is to also enforce policy. Thats why we have GNOME widgets and GTK widgets. The solution is not to have any GNOME widgets but to have GNOME libraries determine policy for GTK widgets.
As I understand it, some of the widgets will be moved into GTK 1.4. (hey guys someone step in and actually say something regarding this..)
What people couldn't comprehend was why fork the code for GnomeHTML. GnomeHTML was forked to CscHTML because Count Zero didn't want any dependency on GNOME and to avoid the library bloat and to avoid circular dependencies. However, I suggest you read the thread to understand fully the issue.
In the end, GnomeHTML will have configure options to not depend on GNOME libraries. So something was worked out.
sri
Is resusable code *really* that great?
There are a few key things which need to be reusable (system libraries, toolkits, and specifically designed embeddable widgets (an HTML renderer, et al)), and as such are reusable.
The reusability of code is a programmer issue, not a technical one. If you want to write code that can be intelligently reused in another application, you have to design the objects involved appropratley. If you want to reuse it, you can right now - drop it in a gtk or, hell, you could put a Motif widget wrapper around it (as jwz was in the process of doing to XEmacs at one point). If you don't want to, is it really worth reusing anyway?
Simple. If you just have to dig a pond *once*, then of course the shovel is easier. But if you dig ponds every single day, then the bulldozer is easier. Remember the formula T(l) + nT(d). Do you perform the task a lot? If so, then the time required to learn a better tool is paid for by the time saved using a better tool. Seems simple to me.
The problem with Windows is that everything is either easy, or *impossible* (or at least extremely difficult). I've worked for years with both, and i've spent far more time beating my head against a wall trying to get Windows to do even trivial tasks, if no Microsoft engineer thought of the task before i did. The joy of Unix is that i can easily combine tools to perform just about any specialized task i can think of.
Yeah, i'm a power user. I'm an experienced programmer. But AS A POWER USER, i consider Windows to be downright user-hostile. At this point, i would not take a job that required me to use Windows rather than Unix/Linux as my primary interface. I'm far, far more productive at my Linux box.
--
Hand me that airplane glue and I'll tell you another story.
Parts of code need to be structures as a graph of connections, but that can get really hard to understand quite quickly. It's nice to break the sections of the code that are graph structured up into small balls that fit into a normal dependancy tree as single entries. This lets one to complex things while still keeping the dependancies in each section simple enough to be understood.
Of course things are a bit more complex than that, but understanding depends on proper abstraction.
I think we've pushed this "anyone can grow up to be president" thing too far.
No. Unix does suck in this area.
Your understanding of components is limited. "Stringing together programs" is not components.
Why? Well, a lot of reasons. One: There is no error handling. Piping text files is one way. There is no way to pass error messages "back" down the pipe. Have you ever tried to debug a complicated shell script that uses a bunch of pipes?
Two: Pipes can't really pass structured data. How do you push a linked list through a pipe? How about a hash table?
Three: All of those "components" are really programs, and their communication is inefficient. Running your example would start at least three full-blown programs, and these programs have to communicate through text files - so data gets copied repeatedly from one address space to another. This is inefficient. If it was a real program using real components, the data would be loaded into memory once, and each object could access it. Much faster!
Yes, on Unix, everything is a file. Probably a text file. So Unix is really good at text files. Did I mention that it's also really good at text files? Yup, if you want to process text files, Unix is great!
X Windows is only the most OBVIOUS problem, because when you are working with graphics, piping files just doesn't cut it anymore. But if Unix had been built on a real component model, and not just the idea of piping text files around, then everything would be better, even at the command prompt. And, XWindows could have used a more powerful system, and then it would have had real cut and paste, real printing capability, real font handling, etc.
So if you agree with Miguel about X, you should also agree with him about Unix in general. The problem with Unix is that the unidirectional piping of unstructured files is not a powerful enough communications model.
This is why Miguel likes Windows: despite all the problems, Windows at least has real components. For TEN YEARS NOW, since Windows 3.0, you have been able to paste a complex object like a drawing into another complex object, like a spreadsheet.
Unix has only begun to pick up this capability in the last year with KDE and Gnome! Ten years late! (More if you consider the Macintosh!)
Torrey Hoffman (Azog)
Torrey Hoffman (Azog)
"HTML needs a rant tag" - Alan Cox
Actually, Miguel is one of the few people who is in a position where doing something about it is actually feasable. Whatever happened to that KDE & GNOME common component archetecure? That would have been a step in the right direction.
I do believe that there is to much ego flying about for a lot of good things to get done. It takes a big man to climb down and say, okay, lets merge. Lets reuse. You can do it better than me, and with OS development kudo is currency, and to loose ego is to loose currancy.
Hmmm... does Miguel have the courage to take a step towards consolidation?
Thad
Thad
I guess it all depends on what your attitude towards what an operating system should be.
I believe that an OS should just provide a good, reliable, secure set of abstractions to deal with hardare and network communication. This allows you maximum flexibility to do whatever you want, which is what Michael is apparently slightly peeved about at this moment.
It is unfortunate that there are no standard libraries for other common functions such as printing. There's been stuff out there, such as TeX's dvi, but the major UNIX corporations in the '80s didn't adopt it. The major UNIX software vendors back then didn't have a decent, cross-platform library to code to, so they all went their own way.
As a counter-example, look at libcurses. It emerged early on as the way to code terminal applications. And now just about any text application you can point to (OSS or proprietary) uses it.
I think the lack of standards in things like printing is more an accident of history than any kind of fundamental design problem with UNIX.
Hmmm.... is it possible that de Icaza is saying that we (that is, the open software community) talk a lot about how good things are, but we don't really deliver the goods. And maybe, just possibly, he is trying to "encourage" the open software developers to do something worthwhile with their skills...
Naw, nobody who is an "open admirer of how Microsoft does software development" could possibly understand the nuiances of reverse psychology. I guess we really do suck...
The terminal does just fine with the components it has. There are quite a few shared libraries, and for (for instance) printing, everything uses lpr - plain and simple. But a drawing model like X does not a application kit make.
Personally, I think that the best approach for an application development framework is a server-based model like BeOS. In Windows, programs duplicate functionality that's handled by one server in BeOS. Linux (and UNIX) is a great command-line environment, and provides a rich environment on top of that. Just don't use X for anything more than xterm, xclock, and xload.
vi is far more difficult to navigate than msdos's edit command.
There are flavors of vi that have pulldown menus (the main advantage of 'edit') but that's not the norm.
vi is an antique editor with it's heritage in the first crt display terminals and crofty old VT-100ish escape sequences. I like it because I can edit files from within a telnet session on OS/2 boxes all over the company where I work, but I seldom fire it up in any environment where a more powerful editor is available. It's universally available, and it can be piped through a tty port, those are it's real values. Not it's power as an editor.
Yeah keep using the same old tools all over again. While you're piping commands in a shell script or reading a perl book I have made a few clicks and completed the task with a new tool.
Can't someone rewrite gzip to automatically tar files like EVERY other archiver on the planet? Lets see what all does this: pkzip, arj, rar, jar, the list continues. Get with the times!
Only the State obtains its revenue by coercion. - Murray Rothbard
Um, ok what differnce does it make if the GUI is embedded in the OS or can be removed? Other then the fact that a buggy gui will prevent you from using your computer or takes up lots of room if you don't need it? You can use linux w/o ever seeing the command prompt if you like. Oh, and the flip side of your GUI is easier then text is text is more powerful then GUI...go figure.
Code-reuse and encapsulation/componentization is in direct opposition of monolithic interdependencies. If they are actually doing this than I suggest they are not designing correctly. Encapsulation should *avoid* interdependency, not increase it. This is all partly due to the awful gui semantic agnostic X. I say stop attempting to build good stuff on mushy cruft. Rip out the cruft and start with a solid foundation. That GNOME and KDE are *another* level on top of widget toolkits, window managers, and X is just too much. Some truly common infrastructure should be built. Not just happily chugging along on divergent paths, than building weird bridges to be "compatible".
It's 10 PM. Do you know if you're un-American?
Today, people want to build GUI apps and he is right to say that UNIX lags behind Windows in reusability in that regard. But this is clearly not a "design flaw" just a lack of a widely used toolkit of common objects.
Miguel is also ignoring the fact that a closed, tightly controlled platform like Windows will always have a higher level of uniformity (and reusabilty) than an open platform which must rely on de facto standards rather than the "king's edict" so to speak. In that sense then openness is a design flaw. No, I don't buy it either... Gnome is on track to provide the kind of high level reusable objects he wants. He should stop whining and write code.
--
--
Nothing to see here. Mooooove along...
> (If you are thinking that GNOME sucks, :
> however, it's probably "because you are using
> Red Hat's version.")
Nope, SuSe 6.4.
And I ejected Gnome when my Panel disappeared for the third time.
BTW, saying that Unix suxx because it has long since ceased to be a platform for innovation is not fair.
I believe this is a matter of usage, and I think that Unix is open enough to allow one to approach computing a new way.
Just replace these protocols by filers, replace these processus by users whose shell would be the processes...
Then you'll have something cool.
You can also change the shell, the hardware, the devices, whatever.
Unix'll sucks only when it'll have been explored "de fond en comble".
In France, we say
"A mauvais valet, point de bons outils"
which means something like
"Bad workers usually complain about their tools"
I understand Miguel can be pissed off by too much work (Gnome, Starzilla, etc.) but he should at least respect what made him a legend.
Hopefully this clumsy remark was only a detail in this article.
--
Trolling using another account since 2005.
If anything, the stuff that sucks is UNIX applications. The reason is that they fail to take advantage of all the standards like ToolTalk and other CDE services. If they did, Netscape would use ToolTalk for all its media handling rather than relying on "helper apps" and "plugins", and would use the XC-APPGROUP extension to embed the handlers in its own window. In fact, it would use Motif for layout, as Motif is capable of doing all the layout HTML needs. If they did, they'd all have the same standard print dialog, and they'd all handle virtually any media type thanks to ToolTalk.
The point is: UNIX doesn't suck. UNIX applications suck. And Linux sucks because it doesn't generally have CDE. UNIX and CDE are excellent pieces of technology.
Sorry if this makes no sense; I just got to work, and it's early. ;-)
www.poak.net
"UNIX sucks because everyone doesn't have to use GNOME."
His argument that there aren't common controls/objects/elements/whatever is certainly valid, but I find it hard to find fault in having flexible building blocks that can be used to build code sharing.
It seems to be a complaint that even the base X system is usuable... that users should be locked into using a much higher-level interface that is more restrictive/defined.
Brian Macy
Unix/Linux is based on 30 year old code and concepts. Some of those concepts were pretty novel at the time, many are still good ideas in theory. DLL hell on Windows is a problem with software installations, Microsoft themselves are guiltier than most with newer DLLs that are not backward compatible (hence the strict interface rules for COM objects). Perhaps th Open Source movement should work on developing a modern OS round a micro-kernel with other services exposed as object based components. Even the 15 year old Amiga had a more advanced OS in many respects than what we all currently use (even if it lacked in many areas). The new Amiga stuff sounds interesting mind you. Just my tupence worth :)
The statement that UNIX has been wrong from the beginning is not what he said.
.NET architecture.
What he said is that there is no innovation going on in UNIX and that number of its fundamental features while attractive to our community, are preventing the whole world from using the operating system.
He cited Apple's work on MacOS X as an example of a team that changed some of the fundamental kernel designs on behalf of "end-users".
Miguel's big point is that there isn't a component model and code reuse simply doesn't happen. He is right on the money with that.
However I don't know about the solution of just copying COM/ActiveX/OLE, especially when Microsoft is now dumping COM in favour its
I suspect Java is in the Linux desktop future whether people want to admit it or not. The Java2 integration on MacOS X that was demonstrated at JavaOne proves how much Microsofts component model for applications is obsolete.
In the rest of his keynote he talked about innovation in specific applications such as mail and the whole INBOX/foldering problem. I hope GNOME (and now SUN and StarOffice/OpenOffice) can address some of the design problems with Microsoft Office.
He did say UNIX sucks, and he is correct, many things about it do, but there is suckage on every platform. His point was we have to fix the things that suck on UNIX and he is not advocating re-doing it from scratch.
"do you think that a bulldozer is easier to operate than a shovel? it also has a longer learning curve. if i then say 'how long will it take you to dig your pond using your shovel as compared to my bulldozer?' then i'm not talkin ease of use but rather power. the shovel is still easier."
Thats a rather poor analogy. Chris WilliamsMore evidence of Miguel's genius can be seen in his critique of Unix in general. Unix is not a platform of innovation. Take the biggest development in all software markets in the last five years: the internet. Unix could never have produced the innovation of the internet...
Miguel's a little confused.
It drives me nuts when people who are a little bit smarter like Miguel, start to think they are really smart, because while he can see problems, he is still not smart enough to see solutions. Allowing for many many window managers is not a mistake, it's the trend: think about skins. No, the problem is that the developers who are writing all the window managers keep starting from scratch, or pay little attention to the other window managers. For example, I like the focus to follow the mouse. I'd like to set that one time in one place, then experiment with different window managers to see which I like (today... :) But you see? That's a simple solution to a problem. There's no need to throw the baby away with the bathwater, which is what Microsoft did. Microsoft was a unix systems house back when they produced DOS, and many features of DOS were modelled from Unix. It took them years and years to reintroduce simple things like memory management and multitasking, and then they set off to create NT, an OS that nobody even wants to clone.
Yep, it's true that some areas of Unix are very weak, like printer drivers, but that's more a reflection of the culture: Unix isn't used on office desktops much. Windows has equally glaring deficiencies: think of how much Windows code gets "reused" every day by hackers exploiting the security holes :)
Nope, Miguel, you are not onto anything big, just another Dvorak in a different suit.
While there are some nice features about components, like anything else it's possible to have too much of a good thing.
Taken to extremes - like our good friends in Redmond - you wind up with many, many applications depending on a large number of common components, with (here's the kicker) at times incompatible APIs. Need BeltchWord 5.0 and FlatuanceDraw 6.2? Can't do that if they each want different versions of the same component.
And then you get situations where an application upgrades a component that the OS/Window Manager depends on.... version control lunacy.
I believe this is called "DLL Hell" in Windows circles.
No thanks Miguel. I like and use GNOME, and I look forward to useful things like a common GNOME printing model, but I also very much indeed like the current UNIX way of doing things with regards to the window manager, X, and the kernel.
Some may see 20 years of development as "stagnant" but I see 20 years of continuous evolution. Cockroaches haven't changed much in 20 million years, because they don't have to - they're pretty damned efficiant as shipped.
Want to learn about race cars? Read my Book
His coolness JWZ is another famous Unix-disliker but thankfully this does not stop him producing excellent hacks for it, gawd bless him.
But on a different tack...
I haven't heard or read any of Miguel's speech, but if the quote about X11's 'non-policy' and crack-smoking is accurate - then for once I think
the lad has gone too far.
What if the MIT guys had built in a big featureful window manager and all manner of other goodies into X originally? Many years later, would those same X guys (Keith Packard among them) be able to knock up a small X server for the Compaq Ipaq handheld and be certain that loads of handy apps will be able to run it? Er... perhaps not.
The first unix kernel written in c was 7k back in 1973. The kernels later grew to a huge and almost unmanagable 32K!!
My point is that unix was innovative in which it was one of the first poineering operating systems that were structed from the ground up. Writing a program thats 7 to 25k is hard if its not structured. However when you get to 15 megs where linux is today its full of bugs and almost unmanagable with c.
I believe c is quite obsolete and c++ is needed to manage larger programs.
Try developing a gui based tic-tak-toe game in c and then in VB or java. You will notice with great languages like VB or java that code reuse and stadard libraries help you can get things done in like a 4th of the amount of time. Windows programming rocks and BIll Gates did a great job of luring developers with technologies like ole, dcom/com, VB, win32 api.
This is why WIndows is so hot today. All the software titles today are Windows only because most coders shudder when they see a terminal with emacs or vi and no VB templates or great api's. Is Windows as good as unix? Of course not. Unix is more scalable and reliable. But all the software is for Windows only because its easier to write for it and the applications can tlak to each other. Can you drag a file from emacs and drop it in a directory in a midnight commander terminal? Of course not. Can you drop a file in Word to the Windows explorer? Yes you can.
I know the win32api has alot of bugs and they are a pain but I get things like waitforthreads() and I can write apps that use the NT security model with minimal fuss. Name such a api on unix?
pthreads are way behind. I do not mean to start a flame war we need code templates and more calls and more reusable code if we ever want to attract more developers to linux. I am very concerned about the amount of bugs on Alan COx's to do list. Linux needs to be rewritten in c++ and use a mirco-kernel and standard api's for programs to cmake calls to the kernel.
Structed programming is still here but its quite obsolete to use it without objects. I just love creating com objects with minimal fuss under Windows, now if I could only do the same thing with cobra in linux then life would be alot easier. As you can tell I would not program under linux if my life required it.
And you never replied when I asked specifically what you would do to trim down the GNOME libraries!! Waving your hands around a proclaiming that "GNOME is too big" isn't very constructive, IMO.
He didn't. He just developed core APIs in C. If you want to bind other languages to the APIs, you really want the APIs to be written in C ( though it's a PITA to do this )
The answers to these problems are well known. Systems like Smalltalk-80 and the Lisp machine were fully integrated, component based environments where everything talked to each other. And almost any language other than C and C++ is better for component-based development and provides reuse.
Check the languages for which there are GTK bindings. It's quite impressive.
I agree with everything here. However, I don't think that Unix necessarily "sucks". We need a poll:
Unix Sucks
Unix doesn't suck
Blue
For example, there is no fstab, it's got /etc/filesystems, formatted like this:
It's not XML, but then XML didn't exist when AIX started using this format.
Smit is one of the best administration tools available for Un*xes, easy enough for anyone to use, yet the poweruser can learn the commands behind it and script them when appropriate.
We all know that there are benefits to having everything controlled by one vendor/source. It's easier to code to, it gives users a more predictable experience, etc. But is that really what we wat from Linux? If not, then it doesn't suck; it's just not going to have the benefits (and trade-offs) of being monolithic.
But if Miguel wanted to help improve the situation, why did he go off developing such a huge software project in C on UNIX? It is C that makes component based development such a pain. C lacks even minimal support for component based development (e.g., no dynamic typing, no reflection), and it is impossible to make large, component based systems in C both robust and efficient: there is no fault isolation--a bad pointer in one component will crash other components unless you put them in separate processes.
The answers to these problems are well known. Systems like Smalltalk-80 and the Lisp machine were fully integrated, component based environments where everything talked to each other. And almost any language other than C and C++ is better for component-based development and provides reuse.
Microsoft does not have the answer. Microsoft's component model, COM, has very serious problems. It's complex because the languages it is based on don't have any support for component based development. And despite its complexity, it is still dumbed down because anything else would be umanageable in C/C++. And it has no fault isolation, meaning that if you load a bunch of COM components and your program dies, you have no idea what went wrong.
In fact, UNIX had an excellent, reusable component model: command line programs that interchange data with files. That's no good for building a graphical desktop, but it was excellent for the UNIX user community--people manipulating lots of data. And that model has been extended to graphical desktops and networked systems in Plan 9 and Inferno, which also address many of the other problems with C/C++ through Alef and Limbo. Or, alternatively, Objective-C and OpenStep managed to build something that support powerful reuse and component based development on top of UNIX. And Java is excellent at supporting both component-based programming, reuse, and fault isolation.
If Miguel genuinely wants to improve the situation, why isn't he using the tools that will let him do so? Why isn't he learning from the long history of component-based development that preceded both him and Microsoft? Why is he copying Microsoft's mistakes and mediocrity? Why isn't he supporting tools that genuinely make a difference rather than encouraging the use of tools (C/C++) that were never intended for this kind of work?
People say about democracy that "it is the worst form of government, until you have tried the others". I think the same is true about UNIX. Gnome and GTK help improve the usability of a flawed tool. As such they are really welcome. But by not addressing the root causes of the problems, we'll probably be here discussing the very same problems again in another 15 years, because everything people complain about UNIX was known 15 years ago, nobody fixed it, and it (and its clone--Windows) still became immensely popular.
Choice is a good thing, yes. The problem with Unix isn't choice.
Choice is a good thing only to a certain extent. On a desktop OS, if everyone chooses to configure how their desktop operates, it's pure hell for computer support. If your're trying to write an application for everyone in your company to use, and everyone wants to use a different Linux distribution, you're likely to run into problems. The problems may only be making sure everyone has the same libraries and kernel revision, but it's still a pain.
It's nice to have choices, but unless you don't have to interact with other people, the choises have to be considerably limited. If you want to set your home Linux system up differently than everyone else, great. The problem occurrs when someone else needs to use that system. That's when a standard way of doing things has to be created and enforced.
put up the notebook and cell phone, go trekking in the Himalayas for a couple of weeks - it'll all look much better then.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
Don't all console apps use curses? Most command line apps are written to work together. gzip is a standard interface for file compression.
Do you have any references (web pages, whatever) that say Miguel is an MS reject?
--
"Oppression and harassment is a small price to pay to live in the land of the free." -- Montgomery Burns.
There's also a town called Hell in Michigan. Everyone there uses Windows.
There's yet another town called White Lake. Nothing happens there.
I was under the impression that the Microsoft Registry was just their IMPLEMENTATION of the registry concept. A very badly-implemented one, to boot.
I think the concept of a registry is a great one - but certainly not the way MS did it!
Here's a little list I've been working on about features for a UNIX registry:
1 - Meta-Data Only!
2 - XML format
3 - Access granted through system only
a) This ensures no 'hidden' entries in registry
4 - Cached for performance benefits (?)
5 - Roll-back features included to return to any previous state
6 - Ability to back up or import any desired application's registry entry
7 - Ability to delete any desired application's registry entry
8 - Versioning, Integrity & Duplication checking included - duplicate entries not allowed!
a) Duplicate entries not allowed
b) Permission system on how to handle version conflicts
9 - Permission system for both read & write access to the registry
Just an idea...but I think it'd make software development a bit easier - you can check on place for where libraries & other things are installed, get version numbers, easily manage multiple versions of libraries, etc.
I'll be sure to tell Ken Thompson and Dennis Ritchie when I see 'em.
Christ
"I'm an old-fashioned type of guy. I worship the Sun and Moon as gods. And fear them."
I hate these "kick 'em in the seat of the pants; I'm going to offend everyone" talks. There's not enough software reuse in the UNIX world? Duh! There's not a whole lot in all of software programming. It's the bane of software engineer's existance!
And, yet, after reading the article, I went to download a bunch of Window Maker dock apps which have reused code.
Go figure!
Anyone have the Unix Magic poster, with the wizard mixing everything up in the shell? That's where it's at with Unix. Nothing is better than Unix at this. It was undeniably brilliant. Tragically, it is out-dated. main(argc, argv) and stdin/stdout and ASCII pipes, command line arguments as ASCII data are unable to support new application concepts. OS-level IPC should at least be more structured than ASCII streams. When Unix purists say but that can be built upon what we have, they are acknowledging Miguel's criticism - Unix is not innovating, applications are. We need a new application architecture at the OS level that is as brilliant and innovative as shell programming was - but in this new era. We should be able to have the modularity and code-reuse of the shell (which, incidentally, is the longest living and most successful code resuse design) with more modern concepts and needs.
How do you go about a project to reduce code? Its an interesting problem, and one that exekernels (a completely miniaml design) or BeOS (a completely closed and highly organized design) might have approached better.
Sorry, but what Gnome and KDE are trying to do was done excellently 10 years ago by NeXT. Right? I really just skimmed the article but it looks as if his major gripes are answered in NeXT/OpenSTEP/Mac OS X.
c.r.
Pal, really... stop it :) you're killing me.
Don't you get it? people don't want to WAIT for shit to get fixed if they can get it at the store TODAY, only it has a box with a 'microsoft' logo on it. It's fun to work on tools that will bring utopia on earth ONCE they're finished. but for productivity, for getting things done, stuff like: 'it is going to get fixed, and if the fixes don't work we all get mad and work together as ONE! Oh yeah baby! (orgasmic cry)' won't work. Trust me. perhaps in 'my own private hobby world', but not in 'the Real World(tm)'. I'm sorry.
--
Never underestimate the relief of true separation of Religion and State.
Ya gedit probably would be a bitch on Solaris, but couldn't you use nedit? I actually perfer nedit as a graphic editor then those other ones i mentioned. At any rate i was trying to point out that the poster was comparing an ancient text editor to a modern gui one, which i thought to be unfair. I think anyone that uses notepad would be capable of using one of the 3 gui editors for linux i mentioned.
:) But since you brought it up; redhat is getting better with its installs. If i remmber correctly, you can pick a default workstation install and off you go. The cd is also bootable.
I didn't say anything about installing windows or linux
Better -- provide an invisible 'bucket' into which all the various links get placed. Require the links to contain information about what the application does, and then have some software mapping to place 'shadow' links where the user can -immediately- see them.
Thus you can -easily- delve down to find anything for a particular application that is supposed to be user visible, immediately find the most important things, and trudge through the filesystem if all else fails.
I think that the 'immediate' bit was the thinking behind microsoft's 'dissapearing menu item trick' where little used things were vanished -- the problem was properly located, but their solution suffers from braindamage.
John
John_Chalisque
One of his main criticisms is that most (large) UNIX apps share little code. Obviously that is not very efficient, but it also has some advantages.
It means that these apps are more self contained and not vulnerable from outside influences (remember the DLL-hell from Win3/Win9x/WinNT ?). If they all use the same shared libraries, new versions (which may be required by some apps) may break lots of other apps.
This can only be avoided by very strong central control. Apple is a good example: Apple has always controlled which apps may be released for it's platform, they must conform to all kinds of standards, both from a technical and from a usability point of view.
This is nice for stability (in theory) and some end-users, but it poses severe restrictions on engineering freedom and using/developing for the platform for fun. Also it is impossible to reach in an Open Source environment IMO.
The upcoming CORBA 3 standard will solve the problems Miguel is talking about. It will simplify creating and using CORBA components and remove obstacles which prevented use of CORBA in the past. Finally CORBA will catch up with COM.
COM already solves all these problems and is very widely used on Windows. CORBA will become useful with the new CORBA 3 standard.
Miguel should implement CORBA 3 supprot in ORBit and convert GNOME and KDE to it. Imagine one desktop based on CORBA 3 components written in any language, not just C or C++.
Rather than having a nice set of reusable stock libraries, such as the win32 api, or gtk, we need a standard broad interface definition. I want to take program Z and replace its file browser dialog. I want to have a standard OS wide spell checking untility. I want to be able to change widowmanagers. I want to be able to drive every single program though scripts. I want to change my ui. I want to change all of this on a whim - some of parts should be changable dynamically, others might need a recompile. I do not want to be stuck with some guys "good idea" of a usable interface.
My point is that most people here are saying we need a complete set of standard libraries. I am saying we need acomplete document describing how a standard libaries should interact. Then we build hundreds of libraries to this standard. The unix way, where everything is a file is a very basic implimentation of this - say I do something like: someprog | sed | cut | awk > file (flags striped), for some task, but find that set|cut|awk is not poweful eneugh. An hour later I can do someprog | perl > file. No changes to someprog no changes to the file. No changes to the mythical pion who depends on post processing the output of someprog.
I want options. I do not want some idiotic stock library designed my some fool.
Do not get me wrong there is no standard dot file format, there is really no standard way of parsing a dot file either. My major gripes with registries would be major gripes that go for any large database, in order for your code to be portable everyone must support that database. Dot files are truely independant because they are written in ascii. Yes I do admit when I do a dir -al it there are 100 dotfiles some of which I don't know what program they belong to.
Security-wise access to dotfiles can be handled just like any other file. You don't need a separate security abstaction to handle it. I have had problems in some cases with GUI dotfile managers like network configuration tools, but if written correctly as a series of keys and entrys it would be very hard to f*ck a dotfile parser up. Well written comments and/or documentation help the user understand whats in a dotfile and be able to configure them.
IMHO there is a fine line between configuration files and well structured dotfiles. For example crontab has a great structure that can be easily edited by humans or by a parser, while the sysV init or BSD are a set configuration scripts which is not that easy to parse by computer and written by hand. Most programmers I think will have a lot more of an easy time programming for dotfiles rather than for the registry. And its great to know just what information your program is saving about you.
Till we realise this and look at it from a consumer point of view I don't see unix or linux on every desktop in the world.
Yes, but it doesn't have to run on every desktop. I would be happy if when I went in to buy a computer they asked, "Do you want Linux, blah, bleh, or Blink OS on it?"
karma is for the weak >)
Forgive my ignorance on the distinctions between the various pieces of software available, but don't Gnome and KDE provide the higher level layer that you're referring to? Or is there something else missing? Know of anyplace I could read up on this sort of thing? I'd do a search, but I'm not exactly sure what to look for.
It's not enough to bash in heads, you've got to bash in minds. - Captain Hammer
Most Unix applications share little or nothing with each other, save for the C library and X libraries. Everything else appears to be an attempt to re-invent the wheel, sometimes coming up with an eccentric triangle instead.
The main advantage is that if a security hole or bug is discovered in a library, an replacement library will resolve the majority of problems. A certain $oftware company does this a lot. The other advantage is that it saves memory.
Gmome appears to be doing more than KDE in this field. Run ldd against a typical Gnome application, and a whole host of component librarires will be linked in - Imlib and others for image rendering, GTKXmHTML for HTML, Gtk and libgnome of course, and so on.
Gnome is standardising on which libraries to use. Unix libraries have become fragmented, with many features duplicated between competing libraries. The present situation elsewhere is a mess, due to it not being controlled.
The only other environment I can see that does something very simillar is Perl, with standard modules available on CPAN. Python may do the same, but I havn't looked at Python closely enough.
But when you actually get around to using those oo pre-fab components, you find that you always have to subclass everything, because the original isn't quite what you need. Open Source allows you to cut-and-paste code. Not the most elegant, but the leanest way to advance on what's already there.
blessings,
"Only in their dreams can men truly be free 'twas always thus, and always thus will be."
--Tom Schulman
Althought you don't expicitly state it, you seem to be implying that OOP encorages more reuse than other programming paradigms, now, while OOP does encorage more reusable code to be written, it had not been shown that this actually generates more reuse in practice.
Thad
Thad
Most of us use linux not because of technical or moral reasons but because we like the interface better.
Actually, I use it because I like the control. Anything that lets me create a home made application server cluster using nothing but IP Masquerade, some command-line programs and my own shell scripts is very cool. I also like the customizability - I was converted when I wrote my first kernel patch. I'm sure I could never have solved the same problem if I were using Windows. (And yes, the problem would have existed in Windows, too.)
It means no competition which stagnates development.
Maybe that's why we haven't seen much new in the way of UI from Microsoft for a while? We do from Macintosh - and that's because it's got actual competition on the desktop market.
Be nice to your friends. If it weren't for them, you'd be a complete stranger.
I don't see how a component architecture is going to especially help here, at least any more than any other object-oriented approach. The question is going to be whether it gives me the functionality I want and whether I can depend on the interface staying the same in new versions. In fact, it could hurt because in a component architecture, the interface is now defined by two separate entities, one for component communication and the other for component interpretation. Either one changes and you are in trouble.
Note the difference though - the highest reusability is achieved if you can design a class such that it can be virtually used across any application domain. The above example is a good example of a class that can be used in an email client, or in a software application that drives an MRI scanner.
However, let's say you designed a class that uses UNIX sockets for communication between two different hosts on the internet (let's forget about the big-endian /little endian issue on this one and assume can be used thruout all unix platforms). Now, you may be able to reuse this class when building such programs as a pop3 server, an email client, a web browser etc. but what good does it do to you when you put it outside of the realm of network applications, for instance, in a math library?
Whereas the INI class that reads/parses parameters can still be of more 'reusability' to you inside a math library than the other UNIX socket class.
So the less abstract the class is (or more tailored to a particular fitness or purpose I should say), the harder it becomes to reuse it accross different application domains.
I hope I'm understood on this issue.
'A lie if repeated often enough, becomes the truth.' - Goebbels
FYI, for the financial year 1999, Microsoft had earnings of $19.75 Billion. IBM had earnings of $87.5 Billion. More to the point however, FY1999 microsoft had a net income of $7.785 billion, while IBM only had a net income of $7.7 billion. Now which one do you think is more profitable?
It takes time. You have to approach it little by little. I've been using it for 10 years, and it _still_ bears new things for me. This is an advantage: it allows you to grow. My recommendation is for you to never learn it; the ensuing love affair will make the PC-heads look like the 'pod people' in Invasion of the Body Snatchers! :-)
P.S. vi does suck. I think it was written to scare people away from unix.
What he is saying is.....
,seven out of ten people I talk to think windows is great) is that it functions the same every where it runs. Most people don't want to learn every option on every application and every platform. Trust me i have experience with computer novices.They want consistency.
I have a crapy graphics card so my whole computer is a piece of crap!!!
Just because UNIX lacks in some resuable code in it's graphical shell it sucks. What about the fact that I can do almost everything i need to maintain a system over a serial port.
Unix needs a lot of changes inorder to become a desktop OS. UNIX was designed for mainframes Three decades ago. X and desktops came into existence decades afterwards. Miguel's analogy is like saying a 1960 automobile doesnot have airbags so it sucks. But the basic engine and chasis design is the same only todays cars have improvements.
Resuable code.... Just count the number of OSes out there that were built using a UNIX kernel.UNIX must have done something right.
I wouldn't say X sucks, I would say X is too old for todays standards. Just like a PDP11 is old by today's standard.
What the *nix world needs a newer grphical shell that defines a standard API that people can utilize. You can write all the Window Managers you want as long as you confirm to that API.
The API should include:
1) Unified standard printing architecture.
2) Resuable components for the primary functions of applications.
3) a standard for user interface (menu options e.t.c) Like edit->prefrences and not tools->options and file properties and every other place .
4) A standard method for software installation. Like src goes here and binaries go here and so on.An API to make installation easy such that icons get put in the menu and links get crated automatically on the desktop.
All this and many more standardizations are key to Unixes entry into the desktop. Standardization doesnot mean one window manager but that the basic UI should remain consistent.
The only reason people like windows (Yes
Till we realise this and look at it from a consumer point of view I don't see unix or linux on every desktop in the world.
I would assert that a "server" OS has different requirements (e.g.,
/bin/sh, to name but a few, almost none of which
security, remote administration via X) than those of a developer's
desktop OS (maximum programmer productivity, tools, etc.). For a
"server" OS, UNIX is great. For a "developer's desktop," anyone
fortunate enough to have used a Lisp Machine will recognize how
unwieldy UNIX (and, to an even greater extent), M$ OSes are.
These traditional OSes are constrained by programming languages (C,
C++, etc.) which fail to provide either any safety at all (i.e., avoid
using pointers) or the ability to dynamically resolve symbols. Thus,
UNIX provides separate address spaces for execution threads because
failure to do so results in system crashes (as M$ OSes and MacIntosh
prove so dramatically).
However, this advantage becomes a drag when:
(1) the code sections of programs grow to be huge (e.g., X-Windows
apps) and performance suffers. So, dynamic link libraries are
implemented to overcome the limitations of separate address spaces
(for code only). As a result, we get more complex memory-management
machinery and dynamic linking machinery to make it all work.
(2) we try to write multi-threaded applications on shared-memory
objects, which is a really handy way to do lots of things. So, to
solve the same fundamental problem for data (in an entirely separate
way from code), we write complicated shared-memory libraries and their
attendant kernel hooks to leap over the per-process firewalls we built
in to solve the first problem. Lest I forget, we also implement
light(er) weight threads to leap over those same walls.
We then solve analogous problems that arise as a result of the user vs
kernel space dichotomy via Yet More, Entirely Separate, Complex
mechanisms (loadable kernel modules, necessity of rebuilding as
opposed to patching running kernels, mmap, etc.).
The Lisp Machine solves all these problems (and other problems you
hear complained about on the Linux kernel mailing lists like
suboptimal kernel memory management) elegantly and with a small set of
mechanisms. No DLLs. No duplication of code (but yet with complete
and total access to all code in the system simultaneously). No kernel
modules. No duplication of linkers.
Because we can't share address spaces easily and without grave danger,
we cannot do the kinds of GUI things that Lisp Machines can (e.g., the
Presentation System), where the "presentation" of an object is
actually neither a bunch of pixels nor a stream of bits, but an
actual, first-class memory object known to all threads like
(importantly) the *mouse* thread. (For example, in the presentation
system, any running thread can ask the mouse thread to "accept" a
filename, at which point *any* filename that has been output in *any*
representation, iconic or textual, in *any* window, at *any* time in
the past or future - as the thread can block waiting for input - is
automatically highlighted, selectable, and capable of restarting the
thread.)
Oh yeah, did I mention you didn't have to learn multiple languages
(C/C++, Makefile,
have a debugger!) just to get around?
If you've never used a Lisp Machine, you have utterly no idea how
totally and completely impoverished the typical software developer's
environment is.
While I think Miguel is right about UNIX, I most certainly do *not*
think Gnome is going to solve these problems. However, a Java
operating system could have some potential to approximate the power of
a Lisp Machine.
You need the features provided by ls combined with the features of grep....
ls ???? | grep ?????
You want to combine a whole bunch of components? You can use a shell script or even perl.
We've got reusable code running out our ears.
Aah, change is good. -- Rafiki
Yeah, but it ain't easy. -- Simba
...to different people (duh!). Questions about GNOME are, to my mind, all about Unix on the desktop. There is no need for GNOME in server space. That is what is so very, very wrong about Windows NT. So if we're talking about *NIX on the desktop (and we are) we're talking about the great unwashed masses. The great unwashed masses are never, ever going to learn the command line syntax for find. Ever. Period.
-- The Sage does nothing, and nothing is left undone. --Lao Tzu
tu stultus es.-IneptE
loev,
Axel
mhm23x3, alt.fan.karl-malden.nose
Don't get me wrong, I love OOP, I'm a C++ programmer, and I do thing OOP makes it easer to create large scale systems and manage complexity, and so on, I'm just pointing out that it hasn't been shown in any kind of scientific way that OO code gets reused more.
Thad
Thad
That's not really what "everything is a file" (EiaF) means. EiaF is really a pretty low-level thing, meaning that all sorts of objects - files, devices, fifos - in a common namespace and are accessed via a common set of syscalls - open, close, read, write, ioctl. This was actually an advance over earlier operating systems which often required that you use different syscalls to get different kinds of descriptors for each kind of entity, and which had multiple namespaces as well. Ew. You can see the power of EiaF not so clearly in UNIX itself, which contains many deviations from the principle, as in Plan 9, which was the "next act" for the UNIX principals.
There are a couple of other principles that you seem to be confusing with EiaF, and I think it's worth discussing them too. One is the idea that files should be unstructured. Again, this is a low-level idea, this time referring only to the "physical" layout of files and to the filesystem interfaces. As a filesystem designer and implementor, I can say this principle is very important. Filesystems have quite enough to do without having to worry about different record types and keyed access and so on - as many pre-UNIX OSes (most notably VMS) did. Man, was that a pain. What gets built in user-space, on top of that very simple kernel-space foundation, is up to you. More complex structures have been built on top of flat files since the very first days of UNIX (e.g. dbm files).
Another related principle is that data should be stored as text whenever possible. This is an idea that's gaining new life with the widespread adoption of XML to represent structured data, and again it's a good one. Doing things this way makes it much easier to write filters and editors and search tools and viewers and such (or to perform many of these tasks manually) than if the data is all binary. It makes reverse engineering of file formats easier, which is a mixed blessing, but it also makes manual recovery and repair easier. Converting to/from text also tends to avoid some of the problems - endianness, word size - that occur with binary data. Obviously there are many cases - e.g. multimedia files - where conversion to/from text is so grossly inefficient that it's not really feasible, but in very many other cases it's just a pain in the ass for the next guy when some lazy programmer decided to dump raw internal data structures in binary form instead of doing it as text.
In conclusion, I'd say that by all means people should try to retain the structure of data. Even better would be if the means for manipulating data could be provided and linked to the data itself in some standard way, like OLE/COM does in the MS world. At the very least, even without a common framework, it would be nice if more programmers would provide libraries with which to manipulate their data files. But please, let's do all this on top of text wherever possible, and let's do that in turn on top of a flat-file kernel abstraction within a single namespace. These are some of the more important principles that led to UNIX being such a success.
Slashdot - News for Herds. Stuff that Splatters.
Ahhhh! I need less mores!
If tits were wings it'd be flying around.
You know, I really admire all the great work Miguel has done. I'm a long time Gnome users and Helix Gnome simply rules. But it's comments like this that make me wonder whether Miguel's the one smoking crack. It's the OS, stupid! It's supposed to manage processes, memory, disk and other resources. It's not supposed to decide policy or provide user level services - that way lies the blue screen of death! Okay, so the X window system sucks. Wow, there's a bulletin. Come up with something better and we can talk. Good God man, you can't even agree with the KDE people on a component architecture, but you're lamenting the fact that UNIX doesn't set policy? Like you'd really be using whatever they came up with anyway?!
Premise: GtkHTML is a Gtk+ widget. (Hence the name "GtkHTML")
GtkHTML depends on GNOME. If GtkHTML is truely a Gtk+ widget, then there is a circular dependancy. (What would happen if GtkHTML was bundled with Gtk+?)
Reality: GtkHTML is NOT a Gtk+ widget. GtkHTML is a mis-named GNOME widget.
Is this confusing to users and developers?
Yes. Either GtkHTML needs to drop GNOME dependancy, or it needs to change its name, and stop pretending to be something which it is not.
Yeah, cause we know everyone on /. are experts on everything, just like yesterday when eveyone and their brother were arguing over how they knew the G4 Cube pic was a fake...
Awww, there is only one beer left and it's Barts.....
Now I know Slashdot is going downhill.
Never have I seen so many misleading and incorrect posts moderated so high. I know why this is, though. Because of the combination of three things:
* He said something bad about UNIX.
* He said something good about Microsoft.
* It was Miguel who said it.
Now by this combination and the hive-like mind of GNU/Linux zealots, rational thought is left aside.
Look people, think for yourselves. Miguel made very valid and very true statements. He has made a number of widely used programs in his past, GNOME only being one of his recent.
Look. I urge you people to think a little. Consider a little. And go back to rational thought. Miguel is also trying solve the problems he finds as well, rather than ignore them like others on this board do.
Fuck the zealotry.
UNIX was built on borrowed VMS principles. VMS is superior to UNIX in more than just a few ways, which are beyond the scope of Slashdot or its moderator's knowledge. That is why you got moderated down. If whoever moderated it down knew the first thing about VMS, he'd have given you an Insightful comment, in spite of it being sarcastic, or at least a funny. I'm not saying Linux or UNIX sucks, I'm only saying that VMS is far superior to any UNIX in existence.
'A lie if repeated often enough, becomes the truth.' - Goebbels
Reusable? Oh, Microsoft's code is reusable alright. In fact, you don't have a choice. The beauty of the UNIX design lies in its modularity. The fact that you can unplug compontents and plug in others. This is what is known as flexibility through modularity, as we all know. Microsoft has included the code for its GUI in the kernel. That is bad design- now you don't have a choice about your GUI, unless you want to muck with the kernel. And another thing.. just because Microsoft Operating Systems have had fancy graphical interfaces doesn't say a damn thing about their functionality. Where are our priorities?
"One of the main reasons Unix is so fragmented and inconsistent, which really is what he's complaining about, is that the whole system (kernel, libs, user interface) never been under a single entity's control. Someone above cited MacOS X as a great example of what Unix can become if it's done right. This is true -- it's easy to be consistent when a single entity controls every aspect of the platform. The problem is, that's not what most Linux users want."
No, that is not what he was complaining about. He was complaining about software not sharing much code and nothing enforcing policy.
He can't twist his words around until he is wrong.
"Where he is completely wrong is his claim that Unix is no longer a platform for innovation. He's got that completely backwards -- indeed, the whole reason for the inconsistency of user interfaces is the very openness and relative simplicity of Unix. Each layer is separate from the next, so it's easy to write a new GUI system on top of the OS without changing any of the underlying layers. And people have done just that, which has led to several generations of X and other apps lying around (Xaw, Motif, OffiX, etc) -- people see a problem with the existing GUI and they reinvent the wheel, leading to a proliferation of incompatible interfaces."
The problem is that all them permutations of interfaces are not innovative, really. They are just different and most often of poor quality.
"The upshot is, because it's open, we have a choice. And choice can lead to inconsistency. So if he wants to work on a platform where everything will always be consistent, he can go work for Apple or Microsoft. Otherwise, he'll just have to make Gnome so good that no one will want to use anything else, because there isn't any way to shove things down people's throats in the *nix world."
Choice isn't an excuse for poor quality.
Those users all had a choice, right?
--
Hand me that airplane glue and I'll tell you another story.
As for MS' R&D dept, yes we've all heard of Bill Labs: 'last one in academia, please turn off the lights.' So far, however, they've just assimilated existing technologies into their own non-interoperable versions e.g. COM.
As for your point on component programming, I'm sure there is room for it in *nix. The only thing I have problem with, is industry's tendency to jump on _one_ approach .. where many are needed. The problem that this hype/hysteria causes is that eventually that one approach is all that remains.
The problem with dot files and /etc is that there never, ever will be standard, reliable engines for parsing and changing those files. Every attempt up to this point of a GUIified system admin interface has failed simply because nobody can trust the output, and you end up back in the text editor anyway.
/etc, and SysV or BSD init are "policies" that everyone has swollowed whole. (I should point out that this is exactly what Apple is doing with it's Unix base, basing it on an XML config engine and NetInfo, which I think is a binary database.)
Now for "Unix" is isn't that big of a deal, because that's what the users like you want, but let's imagine some other OS that is based on Unix but is actually aimed at the average Windows or Mac end user. Reliable GUI system config becomes a absolutely critical issue, and unfortunately it looks like that means that the spaghetti pile of Unix text config files needs to go.
So, while RedHat and Mandrake and the rest of the Linux vendors polish up the installer and the desktop, they haven't gone so far to eliminate the smell of Unix from underneath. Eventually somebody will do so however, and that means a "registry" or XML of some sort. Unix-users won't like it, but despite all of the "no policy" handwaving, the fact is that dot files,
Also, I'd like to agree with Tumbleweed that the problem with Microsoft's Registry is primarily implementation, and that there is a many logical stops between a mess of text files and a large binary database that stores everything from MIME maps, to network config, to everyone's Excel settings, to the last 10 CDs you played. (The biggest problem with the MS registry is the FAT filesystem, however. It is simply impossible for a large file to stay uncorrupted on that filesytem over time, no matter how critical that file is to your system.)
--
Business. Numbers. Money. People. Computer World.
If the tangled mess that is an M$OS, is desirable to anyone, then you have to go back to university. If component 'programming' is desirable to you, then you've probably been raised in the 'e-business' world.
The absence of libraries is due to C not having a large standard library. The absence of large pre-packaged commercial libraries/tools, is due to UNIX's current lack of commercial success.
The supposed 're-use' which OOD or component programming allow, results in bloated apps which survive only thru fater h/w. While the initial creation is easier, the maintenance and performance are not. I'm much more for Niklaus Wirth's "A Plea for Lean Software" than for Miguel's yearning to develop for M$.
But the real issue is something else. All these developers who complain about unix, are fooling themselves if they think the criticism will lead to innovation. At a time when *nix is near dead (yup even linux), such irresponsible nit-picking will lead only to the homogenisation of platforms ... and nothing like the revival of systems research. plan9 is not going to be your next OS; some M$ bloatOS will be.
Well, duh. Did he expect independent commercial software shops to share their code with each other?
Someone please tell me this is a belated April Fools joke!
He goes on to make reasonably valid points about how "reusable components" are available under Windows. What he misses is that this puts other software shops completely at the mercy of the components' owner, Microsoft. Is he proposing a Unix where everyone is similarly dependent on GNOME's components?
OK, GTK+ and Qt provide some nice reusable components. The advantages are obvious. I use them myself. So why is he dredging up all this irrelevant/clueless/scary stuff?
I am a GNOME user, and often defend it when it is unfairly maligned, but I don't think I like the way this is headed. No, not at all. Hopefully he's just talking out his ass rather than presenting a carefully thought-out position.
--
Sheesh, evil *and* a jerk. -- Jade
Vi is a very powerful editor with a seriously sucky interface.
Notepad is a very limp and pathetic editor with a very easy interface.
--
Peter
It was a trolling debut of adorable Miguel --- and what a success! Congratz. Welcome to the trolldom.
Is his comment meant to encompass all of the various "forms" of UNIX? Linux, the various BSD's, etc.?
;-)
It's been my understanding that Linux is not UNIX, but merely looks like it from a command line standpoint and works like it in certain ways.
I thought that was kind of the idea: Linux is a better built UNIX. Of course, I could be wrong. I am wrong from time to time.
Co-founder and designer at Music Nearby: http://musicnearby.com
Just offhand, Trumpet supposedly has an NT kernel clone. I want to say that there's another project, but my memory is going fuzzy on it . . .
Rather than getting into pissing wars of which current OS is "the best", look at it from the standpoint of "what would make a really good OS?"
Unix has survived in part because it does a pretty good job for people who have time to learn the parts they need to know, or have someone else learn that and support the end user. It was also a cheap multiuser OS for the academic world, which gave it some incredible inertia in regards to replacement, after desktop machines became well established.
And then herewas the fact that you had the sources - you could get under the hood and diddle with it. Great for compsci folks, not so useful for most anyone else. And the `386 based *nix varient have given that access to almost anyone who wants it.
But you really can't forget the the general user - the people who want to use the computer the way they use a copy machine or used to use a typewriter. It's those people who create the volume of sales that helps makes the hardware affordable. Ignore them, stick with a nerds' OS, and don't be surprised if later generations of hardware run a certain OS family much better than the non-competitors. Instructions to support driver operations for hardware that has no released documentation, hardware that is tailored to fit that one OS.
Unix has shortcomings. It was the third OS I learned, when I hit the 4th I couldn't help comparing the two and wishing they could be merged. Years later when I first ran into MS-DOS I was amazed at what was missing - no loadable device drivers ? No easy way to extend the CLI ? But the common hardware platfor got rid of things like using control-shift-buckybit for cursor control, and it was somewhat easier to use.
Unix has somewhat remained in the world of the geeks, even though it is slowly spreading. But it still could use some fixing. And the issue of compatibility gets in the way - if you can't run an old app on the new version, is it really *nix?
And the embedded processor world needs something other than Unix (and most certainly something other than WinCE). I don't want to have a 32 bit processor with 8 megs of RAM to control my microwave, when an 8 bit'r with a low footprint embedded OS will do the job. I mean, how often do you really need to use Emacs to prepare dinner?
So don't be mini-BillG types, with one true OS. experiment, come up with alternatives. You'll learn things, and might even create something the non0tech types end up using.
.NET is built around COM - it just exposes a lot of XML based EAI interfaces to allow COM to work with any other component model.
S.
I don't like Gnome , mostly due to usability problems but this guy is right on the money. Lack of unified printing support, complete lack of code reuse ( brilliant example with Netscape, StarOffice etc ...) Hell , even lack of common font support ( some of the apps see TTF fonts others don't ) it all leads to the terrible desktop experience most new users complain about when faced with Linux.
first it was *nix is great, its sooo much better, now it sucks....make up your friggin' minds....
I personally love *nix systems, but sxht, can we keep from changing our views every time someone highly recognized in the community says something contridictory to what we had been saying in the past. yes there are some things about *nix systems that suck, but still.....
gui easier than text? I completely disagree. Text is MUCH easier than gui, if you know what you're doing.
Right now, i'm running a Linux box with two desktops - one has four Eterms and Netscape. The other has four Eterms. I'm logged in as root on two different machines, plus local logins. I'm editing text, viewing text (less and man), and running commands. Really, X is just a way to get me a bunch of convenient terminals. I don't even use the mouse to switch back and forth! I can keyboard from one desktop to the other, one terminal to the other. This is fast, flexible, and efficient. Could i run multiple user ids on different machines easily using gui tools? I don't think so.
With text-based tools, i express myself to my computer using *language*, the most flexible and powerful tool ever invented by humans. With a gui, i can point at shapes and hope they do what i want. A chimp can do that.
--
Hand me that airplane glue and I'll tell you another story.
Rehash: Unix is not Natalie Portman. Duh!
(Note: I wasn't at OLS. I'm getting this from the article.)
Miguel de Icaza shows up at OLS and immediately begins ranting about how bad Unix in general (and Linux in particular) is. Partially, he says, this is because the kernel doesn't decide on any particular "policy" (by which, one can assume he means any number of things), but mostly it's because there is little-to-no code reuse among Unix applications.
By the way - Miguel's (or, at least, Helixcode's) latest project, called Bonobo, is a software component system designed to make code reuse easy. If you're using GNOME, anyway.
It's classic marketing technique: you build up a problem in the mind of a listener, then solve it for him with your product. That doesn't necessarily invalidate it (Unix systems do lack reusable software components, and that's a real problem). It's similar to what John Carmack did at Macworld when he issued that backhanded comment about Mac 3D hardware finally not sucking. We're just not used to hearing it from Open Source people.
- 64 Megs of your memory won't be used just to boot! You'll finally get to see what all the fuss was about all that "speed" ... unless you enjoy blaming your netscape's performance on your ISP;
- no more fortnightly reboots ... unless you're one of those people who turn off their computer 'so it won't get damaged'.
- A data file would be a data file; an executable, an executable. Open any email you want;
- the word 'server' would have meaning again ... unless if you're still unclear on the concept;
- you'll have one real, in the flesh, competent admin for 50 users ... instead of one off-site admin and 50 incompetent mini-admin users struggling to do everything themselves;
- if you don't like a tool ... you replace it! And no need to run a huge monolith to do a small job: OO command-set lets you do *anything* to source files short of making them sing;
- tried and tested virtual memory;
- one stray app won't bring down the system ... unless if you find a blue screen 'soothing';
- remote login. You've got the whole network to run processes on;
- remote display. Work anywhere, from anywhere. Work 'in' the lab ... from *home*.
Top Ten Ways Your NT network Would Improve If Converted To Unix:
- what NT 'network'?! You can't log into another machine; you can't run a process elsewhere; you can't display on another machine; most/every software has to be installed on every machine (you got 100 machines, you install 100 times); no true shared filesystem.
Jobs/Tevian(?) carried the idea of reusable toolboxes from MacOS to UNIX & OOP. The first iteration was NeXT based on ObjectiveC. It has since migrated back to the Mac.
When NeXT bought Apple (or was it the other way around) a couple of years ago, the two companies softwares started merging.
Okay I will respond to both posts here.
First of all the "power/control" you have with linux is simply a consequence of the UI. Windows does not technically prevent you from writing code to perform the same tasks all that is differnt is how you go about accessing the underlying utilites (COM vs. calling a shell program). I would argue that not only the command line but also the host of small utilities are all part of the GNU/linux UI. If we are not using linux for this what are we using it for.
>Linux interfaces have been awful, oh so unimaginably awful, until recently.
This really depends on what you mean by interface. As argued before the command line provides a much superior interface to MAC OS or Windows for those of us with greater technical background. As many people often mean good interface==can be used easily by a newbie linux does have a terrible interface but is that the kind of interface we really want. Now I agree that the graphical user interface is lacking but it is still superior to those other interfaces because it is not restrictive.
Does the standardized windows interface restrict the user. Yes I think it does. We have to go the the control panels to change things (or use special document registry features) we cannot like the guy before mentioned easily write a shell script to change our IP. Suppose I have a list of files which I want to change the name in some specific pattern and copy them to another directory. In linux I can often do this on the command line but not in windows.
Why? because power is taken away from the user in the name of usability by the many.
>This is a classic overreaction. If you have access to a terminal window..[snip]..then you can do whatever you want
Not true. This only occurs if all programs have standard terminal level interfaces which is precisely what I am worried about. If all the new software is writtne in gnome what base do we have at the terminal level to hook into?
If you liked this thought maybe you would find my blog nice too:
However, Miguel focuses heavily on X Windows, where he is more or less correct. X Windows programs are not built in a way to allow them to work together in most cases. One clear exception is window managers. X has the capability to embed one program inside another, but window managers tend to be the only programs to do this. But simply being able to display one program's widgets inside another program's window isn't enough. They must be able to communicate more information to each other to really be able to work together. The idea of components in X is a novel goal, and I wish Miguel the best of luck in making it happen for Unix.
--
For every post, there is an equal and opposite re-post.
Why doesn't Miguel de Icaza pack up his shit and go code VB apps then? Christ, UNIX's power and flexibility come from it's non-structured approach.
Personally, i believe that trying to shoehorn linux into existing desktop configurations is pointless and stupid.
Why are we playing 'catch-up' with MS when these days you can get a java-based office suite online (www.thinkfree.com) which does more than the equivalent GNOME apps do, and pretty much everything that Word/Excel do?
If you want code re-use, etc. etc. then there are a number of options on the Linux platform - Java is a notable one. '
All that will be acheived by imposing 'standards' on linux is what happened to SCO, and what will happen to MS in a few years.
We need to look forward, not back. Make sure that games are supported better on linux than anything else, that it plays, serves and manipulates media better than anything else. When all the kids are using linux, thats the the time that MS will start to really fill its pants.
Linux is a 'Cambrian Explosion' in the OS world.. people (like myself) have come to view it as a tool to empower the single user.. I want to know the hows and whys of how my computer works, i don't want to be a corporate drone bashing away on some shitty word processor all day, without an inkling of the inner workings of it.
I don't want to see Linux turned into another stilted Desktop metaphor like Windows is.
No code reuse? look at Perl!! Theres not many perl programs written, especially in CGI-land that don't use modules. Python is getting there too - its C and C++ that are the dinosaurs, not UNIX.
If theres no community in the C/C++ world, don't make it everyones problem. If C/C++ doesn't have a standard GUI API like Win32, that makes UNIX suck? Theres Motif isn't there?
'Oh, we don't like Motif, so we made a new, different API along with a bunch of other people and now we want to whine cos its too much work to support all this fragmentation.'
so lets just blame the decisions we made on the general crapness of UNIX, shall we?.
Well, thats a load of shit. If you made the wrong choice of language/platform when you started developing your code, thats your problem, not UNIX's.
The OS does not need to be the browser. If GNOME is a good platform, then people will use it. And that will be a standard platform. But don't take away my choice to use KDE if i want to, and don't take away my choice to have 6 different window managers if it suits my purposes.
My 2c
I gots ta ding a ding dang my dang a long ling long
I've been thinking about this for a while, actually. Windows and Macintosh are both pretty well accepted by the mass-market home user. A key reason for this acceptance is their way of hiding all the scary details. Until there is a flavor of Linux that has the droolproofing and sneezeguard that the more popular OS's come with, it will not begin to push Microsoft out of the home market. A lot of people don't want flexibility, as strange as that sounds. They want to be able to git on the Internet. Either Unix developers don't know this, or they decide that they don't care and they only want competent people using their systems. This leads to very flexible, powerful interfaces that scare hell out of the home user (Linux). At the other extreme, you have the drool-proof, detail-hiding interface that nobody with a half a clue wants to use (Win/Mac). To get both user populations, the user interface needs to be able to scale from simple and inflexible to complex and useful without too much trouble, so that lusers can be protected from themselves until they decide that they want more freedom. Sort of a sneezeguard that can be removed in sections. If Linux had this, more people would be able to (at least sort of) use it. I know, I know; it's depressing and it's wrong to gimp up a nice thing. But it will be necessary.
It's a wonder how otherwise-knowledgable people confuse these things. They are lumping everything from the UI down to the sys calls, and petulantly whining about this and that. But their incoherence is missed by the increasing mass of clueless developers who think 'policy vs. mechanism' has to do with the White House.
> However I don't know about the solution of .NET architecture.
> just copying COM/ActiveX/OLE, especially
> when Microsoft is now dumping COM in
> favour its
This statement is like saying that RedHat dumped XWindows in favor of Gnome.
.Net is BUILT with COM. Read the C# spec.
Some things about Unix aren't what they should be (single god-like user in charge of *ALL* administration, ports 0-1024 owned by said godlike user), but it seems that what Miguel is describing is X. X has an ungodly amount of toolkits, none of which really share a large amount of code with one another. Take, for example, GTK and Qt. Or Motif and Athena.
What's needed is, imho, something like the OpenStep specification on top of Linux, where you have a standard set of objects to work with and your display API hides _how_ it actually displays (making an eventual break from X all the more attainable). GNUSTEP is attempting to accomplish this, fyi (www.gnustep.org). I've been a NeXT developer for quite some time and can assure Miguel that every app shares a large amount of code with every other app. Not to mention that, given Objective-C's advantages over C++ and Java, the code you _do_ write can be a whole lot more portable and extensible (categories, poseAs:, etc).
One of the main reasons Unix is so fragmented and inconsistent, which really is what he's complaining about, is that the whole system (kernel, libs, user interface) never been under a single entity's control. Someone above cited MacOS X as a great example of what Unix can become if it's done right. This is true -- it's easy to be consistent when a single entity controls every aspect of the platform. The problem is, that's not what most Linux users want.
Where he is completely wrong is his claim that Unix is no longer a platform for innovation. He's got that completely backwards -- indeed, the whole reason for the inconsistency of user interfaces is the very openness and relative simplicity of Unix. Each layer is separate from the next, so it's easy to write a new GUI system on top of the OS without changing any of the underlying layers. And people have done just that, which has led to several generations of X and other apps lying around (Xaw, Motif, OffiX, etc) -- people see a problem with the existing GUI and they reinvent the wheel, leading to a proliferation of incompatible interfaces.
Hmm, just like KDE and Gnome.
The upshot is, because it's open, we have a choice. And choice can lead to inconsistency. So if he wants to work on a platform where everything will always be consistent, he can go work for Apple or Microsoft. Otherwise, he'll just have to make Gnome so good that no one will want to use anything else, because there isn't any way to shove things down people's throats in the *nix world.
And that's a Good Thing (tm).
As a developer I refuse to link my applications with GNOME because it has taken a few good concepts and gone WAY overboard. GNOME initially seemed to be a set of developer guidelines to promote a common look-and-feel. A few "meta-widgets" were created on top of Gtk+ to promote this. (gnome-stock-this and gnome-stock-that)
This was good. Then someone decided to go even further. More widgets where added. Many of these widgets should have been added at a low level (read Gtk+) but instead where added in at the GNOME level. Now you have widgets that depend on gnome-libs and a fairly incestious circle is starting to emerge where GNOME depends on GNOME and its getting so complicated that no developers I know are willing to shackle thier projects to the great beast that GNOME has become.
Miguel and Co. can't see the forest for the trees. I recently ripped the GNOME out of GtkHTML and created CscHTML (http://www.cscmail.net/cschtml) Miguel and several of the other GNOME developers couldn't comprehend why anyone would do such a thing. They couldn't understand the need for a non-GNOME dependant HTML widget. They couldn't agree that a "Gtk Widget" (GtkHTML) shouldn't depend on GNOME. Circular dependancies are a bad thing. GNOME depends on Gtk. GtkHTML depends on GNOME. Chicken, Egg?
Code re-use is a good thing in moderation. Not every hunk of code needs to be a re-usable object, and interdependancies can be bad if they get out of hand (which they clearly have in the case of GNOME) Miguel has stated many times that the dependancies in GNOME will only GROW as time goes on. He sees interdependancy as a wonderful thing, and is so hell bent on code re-use that he is turning GNOME into a huge monster of code that no one wants to link to because no one wants to depend on 20 or 30 different libs. GNOME needs to be split, some of its libs more appropriately belong in lower level widget sets (such as Gtk+) and some of its items should be stand alone utilities. Trim the fat from GNOME and maybe developers would start to use it again.
All files I could possibly want to edit can be viewed in Emacs. To put it simply there was no need for a reusable component model simply to share data between applications.
Well, Windows has had many ways to share data too (pipes, mailslots, sockets etc etc), but that's not what COM solved.
It's about reusable code, and implementation transparency.
For example, in unix there's not standard way of embedding another application into your own for example.
In Windows, I can embedd other applications into my own, and what's more, I can embedd applications which don't even exist yet! As an example, Office 95 can contain Media Player 7, Even though media player 7 wasn't even around when Office 95 was written.
COM solved a lot more than IPC (IPC was just one convenience).
And yes, I know GNOME and KDE are working it.
As a serveer UNIX is graet but as a desktop it dies suck Like he said thier are no standard usable components that is what he is saying and would have to aggree with him
Don't we wish that all our *nix programs shared DLL files? Then we could have all kinds of code re-use. And when we uprade a DLL we can upgrade all the rest of the software that uses it. Just like Microsoft!!
bash-2.04$
bash-2.04$yes "Don't you hate dialup connections?"| write USERNAME
--
Or in the case of Linux, it sucks less and:
"I'll take the red pill. No! Blue! AAAaaaahhhhhhhhh"
- Monty Python meets the Matrix
Here is my (long) responce to the article about Miguel's talk. I have
paraphased his complaints. I wish i could have heard all of his talk but alas
all I have to go off of is what was on lwn.
* Unix developers are afraid to make decisions.
You are wrong there. Plenty of people have made decisions. The developers of
Motif decided that it would be a good thing for people to have shared code
to use to provide a consistant interface. So they created one, their way. Yet
this decision doesn't seem to have much effect now adays. You didn't like
their decision so you made you own with GNOME, likewise with KDE. This is the
nature of distributed programming. Each programmer makes his own decisions
about what they think is best. If others agree, they use that work and if
not they make thier own programs using thier decisions. Eventually, in most
niches a program shows up that most people are happy with and it becomes a
standard -- for a while.
* Because programmers don't have the gut to make a decision, we end up with
foolish solutions that allow many possiblities.
This is not foolish, nor is it irresponsible. What is foolish is believing
that A) you are always correct, and B) thinking that you can force your
decision on others. Wise jedi master says Wisdom is not knowing
everything but recognising what you do and don't know. The wise programmer
will recognise that a certain part of his work might not be the best possible
way or maybe that one and only one way is not the best way and will make it
easy for other to change it.
* Code reuse is in Unix is low.
Unix has great libraries and code reuse IMHO. One of the reasons that i enjoy
programming on Linux is that the POSIX libraries provide better (API and
performance) networking, threads, interprocces communication, etc, than
windows, mac or java. The other thing i love is The Unix Way (TM). The UNIX
Way says that [programs| libraries| functions] should do one thing and do it
well. When someone who practices The Unix Way needs to do a task that hasn't
been done yet (or the current solution is no longer adequate), like printing,
they will make a small something to provide that service rather than
clobbering it into a big does-it-all application.
The applications listed in the article are bad examples. None of them are
Unix programs; they are Windows programs that were surgicly implanted into
Unix (yes, and that goes for staroffice). At the same time these programs
were pioneers, doing things on Unix that had never been done before.
Therefore, there wasn't any good code or services to reuse, so the developers
had to do it themselves. Furthermore, seeing as how the goal of the companies
that created these programs was the program itself and not to make Unix
better per say, they did it the mega-application way and not the unix way.
As Unix progresses these things will provide themselves. Gtk was provided as
a need to gimp developers, EsounD was spawned from the need of enlightenment
to have flexible sound. Imlib, Loki's MPEG stuff, I could go on. The neat
thing about distributed development is that several solutions can present
themselves at the infancy of a need and then one will evolve into something
better than anyone could decide at the begining. Right now, the need for
naive-user applications is in it's infancy (and will be for several more
years)
* Unix is stale, with no innovation
I concess that unix has been stale at times, but that is not The Unix Way.
Now you are talking in circles. First you say it's bad for there to be many
(individual creative) solutions to a problem, that it is better for everyone
to do things the same way. Then you say that we aren't creative. The main
thing that stiffens creativity is being locked into a certain set of rules,
or way of doing things (libraries). Creativity and productivity are
maximazed when you can adapt something that has already been done - if it is
close enough, else have the option to do it your own new way.
One thing that scares me is all these solutions being dependant upon one
another as is being done in gnome. The first trial is almost never the best.
In order for the Linux (GNU/X/GNOME) system to succeed it must not become
dependant on new ground-breaking code. If all of gnome is bound together
like a ball of rubber bands we will have to either live with it or throw the
whole thing away when it becomes out of date. An application that needs to
reuse filebrowsing code should be able to do so without commiting itself to a
HUGE suite of libraries.
Well can't think of a good closing paragraph. This is too long anyway:)
jackson
.files are lovely compared to binary data files, sure, but you completely miss the point. with .files, there's no telling the format of the file, the file's location in relation to the application, etc. With a 'Registry' using XML data format, there would always be a common place for an application to look for things. Applications would still store their own settings themselves, but they'd put _references_ (hence: META DATA) in the Registry so OTHER apps could find them correctly. This proposal isn't necessarily to make something possible that isn't possible now, it's just so absurdly complex that noone in their right mind would try it now. Hence lots of weird tricks to get around multiple libs, etc. It's just a pain in the ass, and an unnecessary one. The 'UNIX Registry' wouldn't prevent any existing apps from working, and it certainly wouldn't be 'required' for an app to make use of it, which is the beauty of it - completely compatible with all existing apps. But, future apps _could_ be made to use it in the future. The perfect implementation, really.
:)
ASCII format vs XML: You apparently don't know what XML is, I guess. ASCII is a file format. XML is not. You can put XML in an ASCII file format, and that is, actually, what I would propose for this 'UNIX Registry'. You should _always_ be able to look at this stuff with a text editor. Or with vi.
$ cat < /dev/mouse
>And then there are still lots of people who don't care what it looks
>like and still use FVWM/TWM/Virtual Terminals.
It's not that we don't care, but that we want our real estate on
the screen. Eye candy might be nice, but I've never seen anything
with the appearance to get me to give up *any* of my real estate. And
if it can't have any real estate . . .
Yeah to be fair the new mandrake insatller is beautiful.
Didn't do too bad a job on my hardware but missed my soundcard and videocapture card both of which are supported by linux.
The problem with *nix's is trying to find the command. Sure there probably is quite a nice console editor installed but if u dont know it's there then it may as well not be.
>Oh, let me guess, you think that MS became the world's largest and
>most profitable software company without being able to do anything
>right
Microsoft is *neither* of those. IBM alone has *divisions* that have
higher software sales *and* profits than all of microsoft. Microsoft
has a higher valuation in the stock market, but as an economist, I think
it's a bubble.
hawk
Well actually, componentized code reuse implies that some interdependencies will be introduced. It's the same principle as dynamic libraries but at a higher level.
Wow, it seems Miguel was more taken by Microsoft and COM/COM+/DCOM than was obvious from the last time he mentioned components on slashdot. Miguel is right that Unix would benefit from a component model but he needs to put things in historical context.
.NET (cross language inheritance of objects/components) can all be traced back to trying to solve that problem and variations thereof. The early implementations of COM were not some grand ngineering effort to great a modular componentized system but sophisticated hacks to solve the drag N drop problem. This is not to say that MSFT's COM is has not come a long way, after all it has enabled them to create what has been described as the largest software engineering feat of all time. 35 million lines of code and counting.
COM is descended from Object Linking and Embedding which was a way to have objects created in one application to be reusable by another. Basically MSFT's entire component revolution can be traced back to the "drag and drop an Excel spreadsheet into a Word document" problem. Everything that has occurred since then COM+ (reusable components independent of language), DCOM (distributed reusable components) and now
Now on the other hand, Unix applications until very recently did not have the cross communication problem that Windows apps had. Everything is a file, if I want to communicate between applications I simply use a pipe. All files I could possibly want to edit can be viewed in Emacs. To put it simply there was no need for a reusable component model simply to share data between applications.
Now decades after Unix was invented (which predates Windows and COM by over a decade) maybe time has come for that paradigm to shift.
lynx -source http://go-gnome.com | sh
As root.
Fetch an untrusted program from the internet and execute it with root privileges. I love it. At least the Outlook security hole was unintentional.
$ cat < /dev/mouse
MS was in fact a Unix shop...remember XENIX??
You just have to get a Byte Magazine from 198something and you'll see (I saw it myself) that Gates' stratgy was to enforce the use of DOS in the low end and extend XENIX for use in the high end...
Just read it...
As I remember the Next OS, badly written as their code was (see the Fuzz report - it's mentioned in ESR's "Halloween Report')(I'd give the URL but our net nanny has blocked Eric's site today. Probably because the word 'hacker; appears.), it had this part right. Printing was provided by the OS. Programs called the printer object to get printing done.
Which reminds me, how is GNUstep - the NeXTlike GUI for Linux - doing? (Opens a browser window and checks.) Hmm. Progressing but not all that fast. Looks like they are working on Mac OSX compatibility. (?!?) Frankly if I could cut code with any facility (last time I was programming, it was dBase IV), I'd be helping there. The Next OS was a boon to programmers as fas as I could tell. All my firends who did programming for it found it a dream, and very quick.
So why didn't it fly?
The API should include:
1) Unified standard printing architecture.
2) Reusable components for the primary functions of applications.
3) a standard for user interface (menu options etc.) Like edit->prefrences and not tools->options and file properties and every other place.
4) A standard method for software installation. Like src goes here and binaries go here and so on.
5) An API to make installation easy such that icons get put in the menu and links get created automatically on the desktop.
I agree with you that Tools->Options is incredibly brain-dead UI design. But replacing it with Edit->Preferences isn't much better. In fact, I have always wondered why top-level menus always have "File" in the leftmost position. What the hell do I need a "File" for if I've opened Minesweeper or a Calculator? The first toplevel menu option in *every* application should be *application*!
When the first menu deals with the highest level controlled by the application, everything else makes sense -- solitaire games don't have to have confusing and unecessary "File" menus at all. Application menu should have application instance and session management options like "Exit all instances" or "Exit this instance" or "Kill instance..." or even "Remeber-> ObjName-> Property-> state_value". Moreover, the "Application" menu item would be the most sensible place to put the application's "Preferences..." menu option.
Well, UNIX is still taking a while to catch up to making optimal use of late-binding libraries (ELF, etc...). I have been seeing on FreshMeat a quickly increasing number of nifty self contained libraries (components if you want to call them that) to do various useful things, like play MPEGS, etc... I think those will get used more and more, espescially the BSD and LGPL ones that can be linked into commercial programs.
That being said, i think this trend is doing alright, and all is well. I think we should be very careful NOT to build a topheavy microsoft-esqe DCOM like system. We should also be careful to make sure that we don't tie the component model to any one desktop or UI. If you can't write a completely CONSOLE MODE application just as easily as a GUI using the component model, it's a FAILURE. If the X libraries need to be present to compile or use non-gui component based programs, it's a FAILURE.
So to sum up, IMHO we need a UI independant model for the little bits and pieces of code that could really stand to be reused, and it has to be lightweight so we don't waste more memory reusing than we save...
A proposal:
how about making modules that are ELF libraries that all have a standard fuction call to identify themselves, their version, and respond to queries about functionality (this is vague, but it's just an idea and this isn't really my speciality...), and then they can be loaded at runtime, and so a program can consist of mainly code to load a bunch of component modules and connect them in some meaningful way (at least for a simple program...)
*sigh*
---
Play Six Pack Man. I
That is simply not the history of Unix. XOR(XOR)
.. in this case it isn't. New code is usually buggier than older code. But it is almost always way ahead in terms of feature set. This is a delimma. It is also something, just as was mentioned, that propoer code reuse can take care of. With code reuse. Much of the 'new' code can be old code in disguise. It can be reassembled in new ways and placed along side brand new code to offer a very up-to-date package. Without code reuse the delimma remains and you are faced with a choice. I think the point that he was trying to make is that Unix was designed in such a way that code reuse is hindered more than with more sophisticated OSs like NT and BeOS which were designed and developed with OO concepts in mind.
Think about it -- it's silly that GUI programs are calling something that looks "internal" to them to pop up a dialog box. They should be issuing a shell command, like 'dlgmsg "Your repartitioning is complete." -b OK'. Or 'dlgmsg "Do you want to purge your deleted messages?" -b Yes -b No'. /dev/proc/ is massively useful; why don't we have /dev/gui/? It seems to me that the whole Window Manager Bloating Wars came about because we chose to ignore the features of Unix that would have made it easy. Why do we have window handles instead of files (i.e. named pipes created by kde)? Why is changing a window's menus any more complex than 'menubar /dev/gui/win46 -m 0 File -mi 0 0 Open...'? Why is listening for window events harder than parsing /dev/gui/win46?
I know it's a hell of a lot more complicated than that, of course, and I can see a lot of flaws and complications in the above... but hell, maybe the window manager should have to run as root anyway (sarcasm). Does anyone know of a project that tried to do something like this?
I am particularly upset by the remark that whoever decided to allow multiple window managers for X was smoking crack. I mean why are we using linux/unix at all if it isn't a way for us to roll our own UI.
If Miguel is such a great fan of MS software development he might stop to think why linux users aren't running windows. While a few of us might be apostles of RMS the vast majority have no such noble reasons for not using windows...we simply like using linux better. Hell in many respects windows 2000 is technically superior to linux (support for more hardware etc.. etc..) and many of us were using linux when its usability was much less than that of windows.
Most of us use linux not because of technical or moral reasons but because we like the interface better. Windows standardized their interface and thus restricts the user. I, and I think many others, would like to be able to choose what window manager I use..I want to be able to adjust desktop setting from the command line a la xset b/c this lets me script and program my computer the way I want. I want to be able to choose the way my applications look...when they all have the same standardized UI like windows I feel stifled.
I am very afraid that this flexability which linux posseses will be deystroyed by gnome/KDE. As these projects progress more and more programs which could have been implemented on the command line are implemented in gtk. Soon I won't be able to access my settings except by dialog boxes and I will once again be trapped in windows hell.
A standardized interface means several things. It means no competition which stagnates development. Moreover I have never seen a UI which scales well from the non-technical user to the wizard. It is just too difficult especially for something as large as an OS or windows manager. If we standardize our interface we will all need to live with the stupid quirks designed for the non-technical.
If you liked this thought maybe you would find my blog nice too:
NT's APIs are a giant hairy mess, and they don't work as documented. You need to spend hours searching through MSDN and if you are lucky you'll find a piece of sample code that you can use as a template because it'll have the magic undocumented combination of function calls that side-effect (if I have to explain side-effect I'd be wasting my time) enough of NT that the documented call will work. They've been talking about DDE, OLE, VBX blah blah for years and they've never delivered on the promises. Every hot windows app out there is filled with intricate little kluges to make it slick, otherwise you end up with some klunky "yup, it's a VB app" feel. I'm not against intricate little kluges that make an app slick, because end-user code reuse is the real goal, but I just wouldn't brag about the development environment: it's torture.
That and reuse is not a simple as it often
seems. Someone else in this thread said
how usefull say a window INI file decoder
class is for reuse.
I am writing a python script to draw plots.
My previous version used exactly such a decoder
(one which comes with python). Eventually the
language grew beyond what INI files can do,
so I wrote my own.
On the other hand, the one thing which has NOT
changed, is that my program communicates whith
GNUPLOT through a pipe.
Compared with OO-stlye compenentry, pipes are
clunky and difficult. Nonetheless they tend
more usefull, due to their simplicity.
Not that I dissagree with OOP gadgetry.
That INI file decoder made my scratch version
a whole lot easier to write. I'm just saying
that Miguel is wrong, UNIX already allows
reuse in a far more significant way than
Bonobo ever will. Witness the average size
of applications in a windows environment.
It says:
Is it just me, or does this sound like a recipe for duplicating the two-year wait for a first Open Source mozilla? I would have loved to get ahold of a Netscape 4 with the bugs fixed - just think how much better all our worlds would be if the first month of Open Source mozilla development effort had gone on bug fixes before they threw all the software up in the air and started again.If the same happens with StarOffice, then the world and his wife will most surely be running Bill's Linux port of MS-Office before those two years are up and the Open Source versions of Star Office start to appear.
Please - someone - protect StarOffice from premature componentisation! Live now first; live tomorrow next.
--
--
What short sigs we have -
One hundred and twenty chars!
Too short for haiku.
Not that it'll help if you can't compile over 50k of stuff but I think that gcc has a kind of bootstrap installation where it somehow manages to compile itself. Of course I'm probably getting totally confused, as we managed to get a binary distribution for Solaris anyway.
Special Relativity: The person in the other queue thinks yours is moving faster.
The problem is, after "easy" administration Windows works poorly, it remains insecure, inefficient and provides just enough functionality to keep its admin from getting fired. Unix actually works and with complex setp does complex things.
Contrary to the popular belief, there indeed is no God.
I guess the /. community prefers a whole level of abstraction greater than the simplicity of the dotfile (gathering from the about of high scoring registry pundits). I guess I don't know what eXtensible Markup Language is, but when I said ascii file format I meant that it is easy to edit in any text editor with only knowledge of the keys and possible data entries. I do agree there should be a common place for configuration data, but I do not nessicarily believe you need a database (registry) to manage them.
I'll give you an example of my fear with the rpm database. I was trying to get all of the depencies I needed for a program, and then I did something no one should ever do, I forced a rpm in. That not only screwed up the database but forced me to reinstall the entire distribution.
I do not have a problem with the concept of a registry. The concept is interesting and does have its particular benifits on paper. The practice is what worries me. Dotfiles work and they have for years, if it is not broken why try to fix it.
I can only agree at most points(although i don't think there are any wrong with different windowmanagers).
The gnome equivalent of OLE will be great for developers!
Why bloat?
GO GNOME!
There's nothing particularly wrong with Unix-style architecture. It is incredibly flexible, which has been the point all along. Sure, code reuse is a good idea, and the GNOME and KDE folks are proving that it can be done in Unix. But where Unix could really innovate is in interface design. We've got the most flexible, longest surviving mature development environment ever. Let's keep all of that and then give the users kickass interface. X is not the problem. It remains true to the Unix philosophy. The problem is that we're still too hung up on the desktop metaphor (and I don't care how cool the code is, GNOME's interface still sucks). What we need is something new...
DLL's and shared libraries are old school given current state of the art computing and software. What _should_ happen is an application can feel free to drawn upon a multitude of components, each of which is dependant on other components - and it should be possible for multiple versions of older components to exist for legacy reasons. When you install new software, it should only need to install object components that don't exist, and it should just throw them into a large database of components - hell, it should really be able to fetch them across the net if need be. Future operating systems are just databases of code and objects, all of which can reach out to other machines or to the net. This is kind of where ASPs are heading, and what Microsoft is doing with .net - even though the implementation probably won't be very good. My argument is that Linux and Unix are old school for this reason. There are enough lessons learnt from operating systems now, that an advanced generation operating system should just look like a blob of objects sitting around the edge of a tight microkernel. Some of those blobs are going to be device drivers, and some of them are going to be executing tasks. And those objects should be able to migrate across machines. What you can do is sit down at home and have agents and tasks running on your home computer, then later in the day sit down at a cybercafe and have some of those tasks migrate locally - they may even migrate back if you so desire. Some of those tasks may actually run on RNA/biological computers that are 'out there' in the net, and some of that data may sit on a virtual drive out there on the net. This is why in 5-10 years time, Linux will look like a dinosaur. It's much better than Windows, Novell and everything else out there, but it doesn't really look forward, it only looks to be better than what's back there - and that is an important distinction to make.
-- Matthew - matthew.gream@pobox.com, http://matthewgream.net
He says unix sucks because there's no shared, reusable code -- just a bunch of different standalone apps that you have to reinvent the wheel for every time. Now, obviously, he's talking about things like window managers and document editors and browsers, since one of the touted strengths of unix is the strength and versatility of its command-line tools. There's lots of reused code/tools as far as sed, awk, grep, perl, lex, yacc, etc. Every project out there doesn't have to reimplement those. However, there's not much reused code between something like, say, GNOME and KDE. Is it because people are scared of giving too much control to the people that "control" the base components? (I don't see how, seeing as how they would be free/GPL). So, basically, the stuff that HE has done for Unix sucks. And now he's going to fix it. Good, it's about time someone owned up to their own mistakes and decided to fix them.
--- Where's my X.400 protocol decoder?
wouldn't brag about the development environment: it's torture.
Interesting viewpoint, considering it's actually their development environment that's responsible for a lot of their success. They've consistently managed to draw developers to their platform, and one of the reasons is they make it ever-easier to produce apps. Now this doesn't appeal to the "let's make it hard and obscure as possible so we can show we're men" crowd, but to the people who actually have to produce a slick-looking app for the marketing dept. in no time it works all day.
The revolution will NOT be televised.