I learned to type by typing, and I type badly. I make lots of mistakes and backspace is my best friend. I type fast (even given the mistakes), but I don't type well enough for it to be considered "typing" by a true touch-typist.
That said, I am a programmer. Most of what I type is not dictation, but things that I'm thinking about and working out as I go (be it email about a project or code), and I type fast enough by far to keep up with that process. If I am writing code that takes longer to type than to work out, I'm programming in the wrong language or perhaps I'm just writting an outline that someone's going to go back over and re-write later.
In fact, having recently tried out a TouchStream keyboard and having had to convert over to 100% touch-typing, I'm certain that I'm much happier the way I type. I crank out at least 50WPM (not sure how much more, because I've never clocked it), and I really don't like the idea of using my smallest fingers to type some of the most commonly typed keys. If I were going to go touch-typing, I would have to convert to a dvorak layout or use a Kenisis (sp?) keyboard.
Touch typing also worries me in the modern age. I'm in the worst-cast role for touch-typing where I see a lot of HTML and a lot of Perl. QWERTY may be an unfortunate layout for text, but it's not nearly as bad at that as it is at code where the shift-over-extend is the common case. I can't imagine how awful my life would be if I had to contort the 2nd and 3rd finger of my right hand ever time I wanted to type < and >, much less having to type @ with an over-extended 3rd finger of my left hand. Ick!
One area that learning to type correctly would have helped, though, is in typing with my wrists raised. After 15 years of typing, I'm not doing too badly, and have only suffered pain when I went for weeks without much of a break at all, but I'm sure I would have been better off if I had learned to type with my wrists up.
I find the idea facinating that open sourcing your product is a binding contract with the community. You cannot back out unless interest in your product is so low that no one ever bothers to fork it. But time and again we see with efforts like this one or XFree86 that the idea of backing out of an open source stance is actually more harmful than remaining that way. While some will view this as a problem, as a consumer, I view it as a boon.
Even making motions toward open source without going all the way can result in "pseudo-forking" (I'm posting this from a Gnome desktop which was originally created in response to the original licensing terms of the Qt library upon which KDE was based).
It will be very interesting to see what the next few decades bring to the table in terms of open source business practices. I envision a sort of corporate ethics evolving around the benefits and dangers of open source development, and this can only be a healthy process. Much as I think RMS took leave of his senses in the mid-90s (who didn't), I have to say that he nailed it when he decided that the GPL would have the power to change the software industry. I doubt that any other legal tool has been able to so profoundly shape the future of business since the anti-trust laws of early last century.
I'm not sure where that comes from, but I replaced my red hat under Red Hat early on (I like pictures of mushrooms, you see), and I didn't have to be root to do it. I can't remember what I did, but I think it involved creating a new "foot" menu and specifying the icon to use. Took 2 seconds and a mouse, no keyboard required.
You mis-understood me. I meant that if you have a mailing list in-house that, say, 20 people are on and a customer sends a giant message with a 300MB attachment to that list, the mail is replicated out to every user. You can store it in one meta-user's mailbox and give everyone access to that mailbox, but then everyone shares the meta-data (read messages, deleted status, etc).
In Open Exchange, you can have the message "sent" to 20 people, but only exist once with 20 sets of meta-data. Then the people reading the mail can mark it as read, delete it, whatever, but they are not modifying what others see.
An IRC client is an application. GNOME is a desktop environment. Desktop environments should include basic administrative tools (e.g. a text editor, file manager, control panel, etc), but it shouldn't contain full-blown applications. Apart from anything else, it couples application development too tightly to the slow desktop environment development.
You have a point. A really good point. In fact, about 4 years ago the Gnome folks made some substantial changes based on that point. Check out the way Gnome is developed and packaged. A significant distinction is drawn between infrastructure and application, and the "slow desktop environment" that you refer to, often out-paces the application development, but that's fine because they're not tightly coupled.
HOWEVER, Gnome does need reference applications. These applications serve to provide a basic "distribution" if you will, but also they provide developers of equivalent applications with a starting point in terms of features and integration with the desktop.
If you're talking about libraries and infrastructure apps (e.g. nautilus and metacity), then I HAVE to disagree with you. Nautilus got much faster in 2.6, and the move to Metacity in 2.4 was AWAY from sawfish which was getting too feature-laiden and slow (though the Metacity folks have found out the hard way that much of the slow-down was because of features that users DEMANDED be put back, and while Metacity is still fast and light, it's not nearly as fast and light as it was).
It's kind of like saying, "I'm sorry I kicked your dog, but I'm not going to be kicking any more dogs because it seems to get dog owners upset," while kicking the dog several times...
My personal opinion is that Darl actually loves Linux, and he's been working as hard as he can to, on Microsoft's dime, paint the anti-Linux crowd as raving maniacs... I mean, he's not really this broken, is he?
OpenX is, at its core, a set of standard Unix/Linux tools like sendmail, but it presents an exchange-compatible interface to the world. This has many positive results including mailing list management that doesn't require duplication of messages, slick calendar integration, etc.
The bad side? The Web interface, I find klunky as heck. Hopefully this move will result in improvement on that front.
Almost half of what you mention (configuration, internationalization, theming) is GTK stuff, not Gnome.
Much of this functionality that has been trickling into Gtk+ over the last year or two is being moved there from Gnome to allow non-Gnome applications to participate in the desktop, but let's not confuse things like Gtk+ internationalization and accessibility support with Gnome... they work at different levels of abstraction.
Well, except that this doesn't work because you will hardly find 20 applications running parallel on your desktop that support gconf.
Wrong.
I'm running metacity (WM), glade, evolution, xchat, galeon, multiload-applet-2, stickynotes_applet, notification-area-applet, wnck-applet, pam-panel-icon, evolution-wombat, nautilus, xscreensaver (hackish Gnome integration only), gnome-panel, gaim, gnome-terminal (x 11), gdm, gnome-session, bonobo-activation-server, gnumeric, gimp (Gtk+) and a number of other things.
You might not think of bonobo as an application, but I'm going to be pretty upset if it doesn't change when I set a parameter in gconf that tells it to!
Mouse and keyboard settings can be configured within XFCE as well.
And mouse and keyboard settings do NOT comprise accessiblity. Managing accessibility desktop-wide is a HUGE undertaking, and an area in which Windows and MacOS had long held the high ground over Linux, BSD and other POSIX operating systems. We know and understand that some people (like yourself) are going to be very unhappy with the "bloat" associated with supporting people with different needs, but that's why you get to go off and use xfce while the rest of us move forward and operate at a higher level of abstraction.
Your post explains nicely why Gnome's code is bloated, adding 10-15 megabyte of memory- and cpu-eating stuff on top of GTK whose usefulness can be seriously questioned.
Question away, I'll wait.
Check out XFCE to see how you can implement a DE in about 4 megabytes
When you want to change the anti-aliasing mode in your browser and spreadsheet app, does xfce do that for you, or do you have to know how to configure those two apps seperately?
If seperately, wouldn't it be nice if (while continuing to use xfce) those apps could have a convention of some sort that allowed them to communicate that information? Of course, xfce would then want in because there are cases where it could use that information to the advantage of the user.
This is called being a Gnome-compliant window manager. Welcome to the 2000s.
grab yourself a copy of fluxbox or FVWM and get back those many megabytes of useful RAM that would otherwise be wasted on irrelevant "features" like themes and icons
What you're really concerned about isn't memory usage (my task bar, just to use one example, uses a fair amount of memory under Gnome, but most of it is rarely used and often swapped in favor of things like OS file caching, etc.), but FUNCTIONALITY.
For example, a Gnome desktop can universally change the smoothing mode for font rendering across all applications at once to, for example, switch to an LCD display. That (in a generic sense, not just for the one special-case) takes a lot of hooks in a lot of places, and that code and all of its special cases certainly requires my desktop to "think" a lot more about a given chunk of work. Now, there are optimizations to be had, and that kind of thing will get faster over time, but it will never be as fast as back in my fvwm days when I couldn't do that, and the window manager didn't have any real communications path (other than ICCCM) with applications. Then, it was easy... if limited. FVWM didn't have any say in how an application represented data, what direction text was laid out in, what language was being used, what accessibility features were in place, etc., etc. That was back in the good old days when we didn't care about an awful lot of niches. Now we do.
Think of it like stepping up from tokenizing to scanning to parsing to compiling semantics. First you had windows that applications directly managed. Then global window management. Then session management. Gnome is working at a layer above all of that at the "desktop management" level. It's a lot of work, and that can be more cumbersome than just slapping a window up Windows 3.1-style... it also happens to be much more powerful.
The way Fedora installs by default, no you get a... wait for it... Fedora.
But... and I can't say this enough... GNOME IS NOT A TOOLBAR, TASK LIST, WINDOW MANAGER or any of those other things you're thinking of.
Don't like the foot menu? Change it or install a theme that changes it. What Gnome is a set of tools, libraries and interfaces for allowing your desktop (infrastructure, apps, etc) to communicate and for providing a set of standards to which a user can hold their applications accountable (in areas as far-ranging as internationalization, accessibility, configuration, error management, bug-reporting, menu layout, etc).
If you don't like the default background, get another. If you don't like the default theme, get another.
But, don't discount all of Gnome because of these trivialities. That's like saying you don't like Linux because of the default console font.
Why do they keep bolting more and more stuff on ? Isn't it big enough already ?
Simple answer: because it's important and no.
Complicated answer: because it's important and yes.
I like to say (permuting an old saying about open source) that open source succedes because it scratches a niche. The more niches, the more success.
"Gnome" is not a single application, it's a distribution of applications that meet a plethora of needs based on all of the niche audiences that use it.
You can say that having an IRC client is just bloat, but if Gnome didn't have that some people wouldn't be using it, and they'd be using a desktop system that was inclusive of their needs.
I really wish projects would deal with getting stuff actually working and working well (bug-free and fast) before they start adding even more functionality.
Actually, Gnome works pretty damned well circa late 2.6. It's been a long time coming. 2.4 was a big change (as the version numbering implied), and a lot of people had a lot of good and constructive feedback that shaped 2.6. 2.8 is clearly taking the next steps in becoming the desktop environment that we can all rely on, and I'm happy with that.
As for bugs... well, I guess it's a matter of perspective. From where I stand, 2.6 is not bug-free (nothing ever is), but it's moving substantially in that direction (kaizen if you will). As for fast... I run a suite of applications on my desktop at home that do things my poor little 300MHz Pentium 4 years ago could only dream of, so I'm a bad judge. I'm quite happy with the current suite of Gnome video and 3D tools in terms of their response and bandwidth, though. I don't really use a file manager much, so that I can't speak to. The Web tools are slick and fast. The high-level object drag-and-drop seems like it could be faster, so there's a place for improvement.
But seriously, do you think the addition of system configuration tools is going to slow down the desktop?
Gnome (like the linux Kernal and loads of other stuff) is getting way t0o bloated to be useful
Well, let's look at Gnome and the Linux kernel. Both are highly modular, allowing the user to strip away what he/she does not need.
Both have many, large components that provide functionality so powerful that most users DON'T go without, at the expense of resources.
Both address the needs of dozens of niche users (internationalization, accessibility for disabled users, strange hardware, etc).
So... I guess I have to ask... what exactly is the bloat that you're not happy with, and how willing are you to configure your system so that that's not a problem?
I've seen Gnome running on top of Linux on an iPaq, so I'm not really buying the "bloated" party line. I just think you're too lazy to configure it to your needs.
No offense, but that's spoken exactly like someone who has no idea what a desktop environment is.
Gnome is 90% the application libraries that manage inter-process data, configuration, internationalization, accessibility, theming, common invocation semantics, error reporting, etc, etc.
That 10% that you're thinking of (window management, applet baubles, desktop layout, file management, changing the root background, etc.) is nice, but if you still have to have all of Gnome around for the important parts (the applications that integrate with the desktop), what exactly is the point.
If xfce is a Gnome- (and implicityly ICCCM-) compliant window manager, it will work just fine in the Gnome desktop, but that doesn't make it a Gnome-replacement.
What people love to refer to as bloat in Gnome (and KDE for that matter, I'm not playing favorites here) stop seeming like bloat the moment you a) want to know how to configure 20 different applications at once b) want to change all of your applications to use LCD-friendly font-smoothing c) speak a language that isn't the default (and perhaps has strange rules like being written backwards) d) can't see / hear / type / use a mouse / etc. ; or any other sort of desktop-level strangeness.... then you actually want a suite of tools and libraries that support your needs.
Sounds reasonable. This is clearly one of those cases where a little information (especially information filtered through Slashdot and a casual perusal of a screenshot-heavy site;-) can be a dangerous thing.
Thanks for the info on the origins, and like I say: good luck!
You're right, but even more confouding to such a utopian world-view is the fact that much of the "presentation" on the Web is actually designed to make it HARD to find information. I was recently browsing the Web for a new appartment. You would be amazed at how hard rental agencies work to hide the information that they are sharing. Why? Because if they come out and say, "I have an appartment for rent with 3 BR at 853 Bob St. in Podunk, PA", people will see that before they ever get to the site on a search engine like google, and just drive over and talk to the owner.
More examples include visual tricks to both display and hide email addresses such as ajsatexampledotcom.
The bottom line is that the Web has truly turned into a human medium of communication, and unfortunately for the utopian information-sharing crowd, human communication is at least as much about information hiding and obfuscation as sharing.
There are about 2000 themes for various desktop systems (from Gnome to KDE to WindowMaker) and of those there are probably about 20-30 that are solid enough that I would consider them full default-theme replacements.
Are you refering to all of those, or did you just install some random distribution and declare it "ugly" (by your standards)? Are you refering to the lack of 3D acceleration on the desktop (e.g. what MacOS/X gets from having written their desktop on top of an Open/GL layer)? If so, that's a valid concern, but starting with the work x.org has done and implementing the rest would certainly have been easier than writing from scratch.
Question: Is there any way to use Linux device drivers with this os?
Probably not, and even if this OS were able to take advantage of Linux drivers, I doubt that it could take advantage of the larger subsystems like filesystems, networking stacks, cryptography, etc.
What I'd really like to see is some of these (obviously massively talented) people who go off and do their own thing, actually starting with a working system like BSD or Linux, but building something of their own, not just a distribution.
For example, these folks seem to want a system designed for the end-user with lots of media features... ok, so why wouldn't you start with a Linux kernel that supports just about every graphics and sound board on the planet... then layer on pieces as needed. Perhaps a modified X server would help, perhaps not... use it if you need it. Perhaps the filesystems aren't quite up to what you want, but you can always modify existing code. Maybe gstreamer is a good support library for what you're doing, perhaps not.
Well, you get the idea.
When Linus started off, he wanted something that didn't exist. BSD wasn't actually available for x86 yet, and down-porting it from Suns and VAXen was more work than he could afford. Meanwhile, Minix was too limited to even work as a good starting point. That's no longer the case, and efforts like this one seem to me much like Linus having decided that he wanted to write his little terminal server by first designing his own system bus.
Still, I wish them all the luck in the world. I hope it works out well for them... it's just that I can't help thinking about how much more they could do with a good starting point.
I agree with the industry. Tax dollars should be handed out to corporations as a way to compensate them for their losses to P2P networks. I think that check comes to about -$2B... please make that check payable to "US Taxpayers". Thanks.
Residents of other countries should petition their governments to put the music companies on the same dole.
Yes and no... it depends on what level of development you're talking about. C and C++ are used throughout (I'm guessing) both of our environments, but your avergage in-house coder for operations or end-user apps is probably not going to be writing in those languages. In high-tech firms that are bringing new solutions to the business world (e.g. software spin-offs from accademia, scientists writing code to support their work, Linux and/or Unix admins trying to get work done) you're going to see a lot of the sorts of high-level languages that are available in that world.
In the insurance companies and other non-technical companies that have a lot of technology dependencies, you're probably going to see much more of the proprietary systems (like VB) in use because they feel more comfortable with something that comes with a salesman (I'm not saying that in a negative way, it's just my experience).
Ok, that was your problem, right there. The languages you refer to may be widely used in YOUR industry, and thus have libraries that you need in that industry, but I assure you that in MY industry, Perl (given CPAN) is far-and-away the best tool for most jobs BECAUSE of its ubiquity and support libraries for just about anything you would ever want to do.
That doesn't say your language is useless, but clearly you're only looking at a small slice of the world.
when you distribute code that uses these modules, the end user must install them
When you distribute code that requires Gnome, the user must install Gnome.
When you distribute code that requires glibc2.2 the user must install glibc2.2.
When you distribute code... is this getting through?
If your program is distributed to Linux systems, you can easily build an apt tree that includes the modules on which you depend as RPMs (or DPKGs for Debian) and then the user just adds you to their sources.list. Alternatively, you could submit your program to CPAN with apprpropriate dependency info, and the user will automatically install the dependencies.
None of this is hard, in fact this is WHY CPAN is so popular.
I only looked at a handfull of the links. It's sort of a Yahoo! (the original indexer, not todays search engine-cum-kitchen sink) for Python code, which is ok, but check out how one uses CPAN in the real world:
# perl -MCPAN -e shell cpan> i/SpamAssassin/ Distribution F/FE/FELICITY/Mail-SpamAssassin-2.63.tar.gz Modul e Mail::SpamAssassin (F/FE/FELICITY/Mail-SpamAssassin-2.63.tar.gz) cpa n> install Mail::SpamAssassin ---- Unsatisfied dependencies detected during [F/FE/FELICITY/Mail-SpamAssassin-2.63.tar.gz] -----
Filter::Simple Shall I follow them and prepend them to the queue of modules we are processing right now? [yes]
I'm sure you can see how this makes CPAN far more useful for building a large repository of useful Perl modules. How, in Python, can you build several layers of libraries that depend on each other without this kind of repository of dependency information? How does a user "come into the know" about these factors?
Of course, that ignores the fact that CPAN modules all come with regression testing and online documentation (installed in the sytem "man" tree) as well.
LOC isn't a great measure, but when talking about CPAN there are several things to keep in mind that modify the premise of measuring LOC:
Perl modules on CPAN include their own, customized installation and testing harness. This renders them far more valuable than a simple dumping ground of LOC.
CPAN presents a searchable, globally mirrored database of this code, which again increases its value.
Perl itself has an extremely powerful syntax. Many of Perl's detractors, in fact, will claim that this is far too much power to have in a syntax (vs. grammar and/or semantics and/or external libraries), so comparing 1000 LOC in Perl to 1000 LOC in, say, Java or C# or other "mid-level languages" (my phrase) can be quite favorable to Perl. Even comparing to other high-level languages can be, depending on the application (of course, each high level language has its own strengths, and for example, Python's thread handling is much simpler than Perl's, and both Ruby and Python make OO much easier).
That said, I think that the idea that comparing LOC in, say, a Red Hat distribution to LOC in CPAN is valuable, regardless of the fact that structure and format are also concerns. They are equally concerns in both environments, and both environments have roughly equal pressures on improving both incrementally over time (e.g. bad code gets migrated away from the core and good code gets migrated in).
ALL OF THAT aside, Perl's CPAN is most valuable not because of its size or the quality of the code, but because it is a repository where thousands of people with highly specialized needs share code with each other. Perl is unique in having created such a space that is widely used outside of core advocates of the language. I don't know why that's the case, but as long as it is, it's a very good thing.
Getting code noticed by your niche's peers and making it available for everyone to use is key to Perl's success as a language.
Slashdot Mirror
Hooey.
I learned to type by typing, and I type badly. I make lots of mistakes and backspace is my best friend. I type fast (even given the mistakes), but I don't type well enough for it to be considered "typing" by a true touch-typist.
That said, I am a programmer. Most of what I type is not dictation, but things that I'm thinking about and working out as I go (be it email about a project or code), and I type fast enough by far to keep up with that process. If I am writing code that takes longer to type than to work out, I'm programming in the wrong language or perhaps I'm just writting an outline that someone's going to go back over and re-write later.
In fact, having recently tried out a TouchStream keyboard and having had to convert over to 100% touch-typing, I'm certain that I'm much happier the way I type. I crank out at least 50WPM (not sure how much more, because I've never clocked it), and I really don't like the idea of using my smallest fingers to type some of the most commonly typed keys. If I were going to go touch-typing, I would have to convert to a dvorak layout or use a Kenisis (sp?) keyboard.
Touch typing also worries me in the modern age. I'm in the worst-cast role for touch-typing where I see a lot of HTML and a lot of Perl. QWERTY may be an unfortunate layout for text, but it's not nearly as bad at that as it is at code where the shift-over-extend is the common case. I can't imagine how awful my life would be if I had to contort the 2nd and 3rd finger of my right hand ever time I wanted to type < and >, much less having to type @ with an over-extended 3rd finger of my left hand. Ick!
One area that learning to type correctly would have helped, though, is in typing with my wrists raised. After 15 years of typing, I'm not doing too badly, and have only suffered pain when I went for weeks without much of a break at all, but I'm sure I would have been better off if I had learned to type with my wrists up.
I find the idea facinating that open sourcing your product is a binding contract with the community. You cannot back out unless interest in your product is so low that no one ever bothers to fork it. But time and again we see with efforts like this one or XFree86 that the idea of backing out of an open source stance is actually more harmful than remaining that way. While some will view this as a problem, as a consumer, I view it as a boon.
Even making motions toward open source without going all the way can result in "pseudo-forking" (I'm posting this from a Gnome desktop which was originally created in response to the original licensing terms of the Qt library upon which KDE was based).
It will be very interesting to see what the next few decades bring to the table in terms of open source business practices. I envision a sort of corporate ethics evolving around the benefits and dangers of open source development, and this can only be a healthy process. Much as I think RMS took leave of his senses in the mid-90s (who didn't), I have to say that he nailed it when he decided that the GPL would have the power to change the software industry. I doubt that any other legal tool has been able to so profoundly shape the future of business since the anti-trust laws of early last century.
Sorry, don't have one handy right now, and I don't specifically recall what I did.
I'm not sure where that comes from, but I replaced my red hat under Red Hat early on (I like pictures of mushrooms, you see), and I didn't have to be root to do it. I can't remember what I did, but I think it involved creating a new "foot" menu and specifying the icon to use. Took 2 seconds and a mouse, no keyboard required.
You mis-understood me. I meant that if you have a mailing list in-house that, say, 20 people are on and a customer sends a giant message with a 300MB attachment to that list, the mail is replicated out to every user. You can store it in one meta-user's mailbox and give everyone access to that mailbox, but then everyone shares the meta-data (read messages, deleted status, etc).
In Open Exchange, you can have the message "sent" to 20 people, but only exist once with 20 sets of meta-data. Then the people reading the mail can mark it as read, delete it, whatever, but they are not modifying what others see.
Very slick stuff.
An IRC client is an application. GNOME is a desktop environment. Desktop environments should include basic administrative tools (e.g. a text editor, file manager, control panel, etc), but it shouldn't contain full-blown applications. Apart from anything else, it couples application development too tightly to the slow desktop environment development.
You have a point. A really good point. In fact, about 4 years ago the Gnome folks made some substantial changes based on that point. Check out the way Gnome is developed and packaged. A significant distinction is drawn between infrastructure and application, and the "slow desktop environment" that you refer to, often out-paces the application development, but that's fine because they're not tightly coupled.
HOWEVER, Gnome does need reference applications. These applications serve to provide a basic "distribution" if you will, but also they provide developers of equivalent applications with a starting point in terms of features and integration with the desktop.
If you're talking about libraries and infrastructure apps (e.g. nautilus and metacity), then I HAVE to disagree with you. Nautilus got much faster in 2.6, and the move to Metacity in 2.4 was AWAY from sawfish which was getting too feature-laiden and slow (though the Metacity folks have found out the hard way that much of the slow-down was because of features that users DEMANDED be put back, and while Metacity is still fast and light, it's not nearly as fast and light as it was).
It's kind of like saying, "I'm sorry I kicked your dog, but I'm not going to be kicking any more dogs because it seems to get dog owners upset," while kicking the dog several times...
My personal opinion is that Darl actually loves Linux, and he's been working as hard as he can to, on Microsoft's dime, paint the anti-Linux crowd as raving maniacs... I mean, he's not really this broken, is he?
OpenX is, at its core, a set of standard Unix/Linux tools like sendmail, but it presents an exchange-compatible interface to the world. This has many positive results including mailing list management that doesn't require duplication of messages, slick calendar integration, etc.
The bad side? The Web interface, I find klunky as heck. Hopefully this move will result in improvement on that front.
Almost half of what you mention (configuration, internationalization, theming) is GTK stuff, not Gnome.
Much of this functionality that has been trickling into Gtk+ over the last year or two is being moved there from Gnome to allow non-Gnome applications to participate in the desktop, but let's not confuse things like Gtk+ internationalization and accessibility support with Gnome... they work at different levels of abstraction.
Well, except that this doesn't work because you will hardly find 20 applications running parallel on your desktop that support gconf.
Wrong.
I'm running metacity (WM), glade, evolution, xchat, galeon, multiload-applet-2, stickynotes_applet, notification-area-applet, wnck-applet, pam-panel-icon, evolution-wombat, nautilus, xscreensaver (hackish Gnome integration only), gnome-panel, gaim, gnome-terminal (x 11), gdm, gnome-session, bonobo-activation-server, gnumeric, gimp (Gtk+) and a number of other things.
You might not think of bonobo as an application, but I'm going to be pretty upset if it doesn't change when I set a parameter in gconf that tells it to!
Mouse and keyboard settings can be configured within XFCE as well.
And mouse and keyboard settings do NOT comprise accessiblity. Managing accessibility desktop-wide is a HUGE undertaking, and an area in which Windows and MacOS had long held the high ground over Linux, BSD and other POSIX operating systems. We know and understand that some people (like yourself) are going to be very unhappy with the "bloat" associated with supporting people with different needs, but that's why you get to go off and use xfce while the rest of us move forward and operate at a higher level of abstraction.
Your post explains nicely why Gnome's code is bloated, adding 10-15 megabyte of memory- and cpu-eating stuff on top of GTK whose usefulness can be seriously questioned.
Question away, I'll wait.
Check out XFCE to see how you can implement a DE in about 4 megabytes
When you want to change the anti-aliasing mode in your browser and spreadsheet app, does xfce do that for you, or do you have to know how to configure those two apps seperately?
If seperately, wouldn't it be nice if (while continuing to use xfce) those apps could have a convention of some sort that allowed them to communicate that information? Of course, xfce would then want in because there are cases where it could use that information to the advantage of the user.
This is called being a Gnome-compliant window manager. Welcome to the 2000s.
grab yourself a copy of fluxbox or FVWM and get back those many megabytes of useful RAM that would otherwise be wasted on irrelevant "features" like themes and icons
And for those who thought the above made sense:
See FVWM themes here and Fluxbox themes here both of which are full of fine icons....
What you're really concerned about isn't memory usage (my task bar, just to use one example, uses a fair amount of memory under Gnome, but most of it is rarely used and often swapped in favor of things like OS file caching, etc.), but FUNCTIONALITY.
For example, a Gnome desktop can universally change the smoothing mode for font rendering across all applications at once to, for example, switch to an LCD display. That (in a generic sense, not just for the one special-case) takes a lot of hooks in a lot of places, and that code and all of its special cases certainly requires my desktop to "think" a lot more about a given chunk of work. Now, there are optimizations to be had, and that kind of thing will get faster over time, but it will never be as fast as back in my fvwm days when I couldn't do that, and the window manager didn't have any real communications path (other than ICCCM) with applications. Then, it was easy... if limited. FVWM didn't have any say in how an application represented data, what direction text was laid out in, what language was being used, what accessibility features were in place, etc., etc. That was back in the good old days when we didn't care about an awful lot of niches. Now we do.
Think of it like stepping up from tokenizing to scanning to parsing to compiling semantics. First you had windows that applications directly managed. Then global window management. Then session management. Gnome is working at a layer above all of that at the "desktop management" level. It's a lot of work, and that can be more cumbersome than just slapping a window up Windows 3.1-style... it also happens to be much more powerful.
It depends on the distribution that you use.
... wait for it ... Fedora.
... and I can't say this enough ... GNOME IS NOT A TOOLBAR, TASK LIST, WINDOW MANAGER or any of those other things you're thinking of.
The way Fedora installs by default, no you get a
But
Don't like the foot menu? Change it or install a theme that changes it. What Gnome is a set of tools, libraries and interfaces for allowing your desktop (infrastructure, apps, etc) to communicate and for providing a set of standards to which a user can hold their applications accountable (in areas as far-ranging as internationalization, accessibility, configuration, error management, bug-reporting, menu layout, etc).
If you don't like the default background, get another. If you don't like the default theme, get another.
But, don't discount all of Gnome because of these trivialities. That's like saying you don't like Linux because of the default console font.
Why do they keep bolting more and more stuff on ? Isn't it big enough already ?
Simple answer: because it's important and no.
Complicated answer: because it's important and yes.
I like to say (permuting an old saying about open source) that open source succedes because it scratches a niche. The more niches, the more success.
"Gnome" is not a single application, it's a distribution of applications that meet a plethora of needs based on all of the niche audiences that use it.
You can say that having an IRC client is just bloat, but if Gnome didn't have that some people wouldn't be using it, and they'd be using a desktop system that was inclusive of their needs.
I really wish projects would deal with getting stuff actually working and working well (bug-free and fast) before they start adding even more functionality.
Actually, Gnome works pretty damned well circa late 2.6. It's been a long time coming. 2.4 was a big change (as the version numbering implied), and a lot of people had a lot of good and constructive feedback that shaped 2.6. 2.8 is clearly taking the next steps in becoming the desktop environment that we can all rely on, and I'm happy with that.
As for bugs... well, I guess it's a matter of perspective. From where I stand, 2.6 is not bug-free (nothing ever is), but it's moving substantially in that direction (kaizen if you will). As for fast... I run a suite of applications on my desktop at home that do things my poor little 300MHz Pentium 4 years ago could only dream of, so I'm a bad judge. I'm quite happy with the current suite of Gnome video and 3D tools in terms of their response and bandwidth, though. I don't really use a file manager much, so that I can't speak to. The Web tools are slick and fast. The high-level object drag-and-drop seems like it could be faster, so there's a place for improvement.
But seriously, do you think the addition of system configuration tools is going to slow down the desktop?
Gnome (like the linux Kernal and loads of other stuff) is getting way t0o bloated to be useful
Well, let's look at Gnome and the Linux kernel. Both are highly modular, allowing the user to strip away what he/she does not need.
Both have many, large components that provide functionality so powerful that most users DON'T go without, at the expense of resources.
Both address the needs of dozens of niche users (internationalization, accessibility for disabled users, strange hardware, etc).
So... I guess I have to ask... what exactly is the bloat that you're not happy with, and how willing are you to configure your system so that that's not a problem?
I've seen Gnome running on top of Linux on an iPaq, so I'm not really buying the "bloated" party line. I just think you're too lazy to configure it to your needs.
No offense, but that's spoken exactly like someone who has no idea what a desktop environment is.
Gnome is 90% the application libraries that manage inter-process data, configuration, internationalization, accessibility, theming, common invocation semantics, error reporting, etc, etc.
That 10% that you're thinking of (window management, applet baubles, desktop layout, file management, changing the root background, etc.) is nice, but if you still have to have all of Gnome around for the important parts (the applications that integrate with the desktop), what exactly is the point.
If xfce is a Gnome- (and implicityly ICCCM-) compliant window manager, it will work just fine in the Gnome desktop, but that doesn't make it a Gnome-replacement.
What people love to refer to as bloat in Gnome (and KDE for that matter, I'm not playing favorites here) stop seeming like bloat the moment you a) want to know how to configure 20 different applications at once b) want to change all of your applications to use LCD-friendly font-smoothing c) speak a language that isn't the default (and perhaps has strange rules like being written backwards) d) can't see / hear / type / use a mouse / etc. ; or any other sort of desktop-level strangeness.... then you actually want a suite of tools and libraries that support your needs.
Sounds reasonable. This is clearly one of those cases where a little information (especially information filtered through Slashdot and a casual perusal of a screenshot-heavy site ;-) can be a dangerous thing.
Thanks for the info on the origins, and like I say: good luck!
You're right, but even more confouding to such a utopian world-view is the fact that much of the "presentation" on the Web is actually designed to make it HARD to find information. I was recently browsing the Web for a new appartment. You would be amazed at how hard rental agencies work to hide the information that they are sharing. Why? Because if they come out and say, "I have an appartment for rent with 3 BR at 853 Bob St. in Podunk, PA", people will see that before they ever get to the site on a search engine like google, and just drive over and talk to the owner.
More examples include visual tricks to both display and hide email addresses such as ajsatexampledotcom.
The bottom line is that the Web has truly turned into a human medium of communication, and unfortunately for the utopian information-sharing crowd, human communication is at least as much about information hiding and obfuscation as sharing.
Define ugly graphics.
There are about 2000 themes for various desktop systems (from Gnome to KDE to WindowMaker) and of those there are probably about 20-30 that are solid enough that I would consider them full default-theme replacements.
Are you refering to all of those, or did you just install some random distribution and declare it "ugly" (by your standards)? Are you refering to the lack of 3D acceleration on the desktop (e.g. what MacOS/X gets from having written their desktop on top of an Open/GL layer)? If so, that's a valid concern, but starting with the work x.org has done and implementing the rest would certainly have been easier than writing from scratch.
Question: Is there any way to use Linux device drivers with this os?
Probably not, and even if this OS were able to take advantage of Linux drivers, I doubt that it could take advantage of the larger subsystems like filesystems, networking stacks, cryptography, etc.
What I'd really like to see is some of these (obviously massively talented) people who go off and do their own thing, actually starting with a working system like BSD or Linux, but building something of their own, not just a distribution.
For example, these folks seem to want a system designed for the end-user with lots of media features... ok, so why wouldn't you start with a Linux kernel that supports just about every graphics and sound board on the planet... then layer on pieces as needed. Perhaps a modified X server would help, perhaps not... use it if you need it. Perhaps the filesystems aren't quite up to what you want, but you can always modify existing code. Maybe gstreamer is a good support library for what you're doing, perhaps not.
Well, you get the idea.
When Linus started off, he wanted something that didn't exist. BSD wasn't actually available for x86 yet, and down-porting it from Suns and VAXen was more work than he could afford. Meanwhile, Minix was too limited to even work as a good starting point. That's no longer the case, and efforts like this one seem to me much like Linus having decided that he wanted to write his little terminal server by first designing his own system bus.
Still, I wish them all the luck in the world. I hope it works out well for them... it's just that I can't help thinking about how much more they could do with a good starting point.
Well, it makes sense for them to make a PR push now, then doesn't it?
Branding is key, and these folks have a chance to ride on I, Robot's brand for a short while... they clearly are taking it.
I agree with the industry. Tax dollars should be handed out to corporations as a way to compensate them for their losses to P2P networks. I think that check comes to about -$2B... please make that check payable to "US Taxpayers". Thanks.
Residents of other countries should petition their governments to put the music companies on the same dole.
Get a sense of humour, pedophilia is really, really, really funny
Get a therapist.
Those of us who've been the victims of such "humour" are not amused.
Yes and no... it depends on what level of development you're talking about. C and C++ are used throughout (I'm guessing) both of our environments, but your avergage in-house coder for operations or end-user apps is probably not going to be writing in those languages. In high-tech firms that are bringing new solutions to the business world (e.g. software spin-offs from accademia, scientists writing code to support their work, Linux and/or Unix admins trying to get work done) you're going to see a lot of the sorts of high-level languages that are available in that world.
In the insurance companies and other non-technical companies that have a lot of technology dependencies, you're probably going to see much more of the proprietary systems (like VB) in use because they feel more comfortable with something that comes with a salesman (I'm not saying that in a negative way, it's just my experience).
I hope you meant "sixteen-year-old", taking it from the realm of REALLY sick and twisted to merely wrong. :-/
industry standard languages
Ok, that was your problem, right there. The languages you refer to may be widely used in YOUR industry, and thus have libraries that you need in that industry, but I assure you that in MY industry, Perl (given CPAN) is far-and-away the best tool for most jobs BECAUSE of its ubiquity and support libraries for just about anything you would ever want to do.
That doesn't say your language is useless, but clearly you're only looking at a small slice of the world.
when you distribute code that uses these modules, the end user must install them
When you distribute code that requires Gnome, the user must install Gnome.
When you distribute code that requires glibc2.2 the user must install glibc2.2.
When you distribute code... is this getting through?
If your program is distributed to Linux systems, you can easily build an apt tree that includes the modules on which you depend as RPMs (or DPKGs for Debian) and then the user just adds you to their sources.list. Alternatively, you could submit your program to CPAN with apprpropriate dependency info, and the user will automatically install the dependencies.
None of this is hard, in fact this is WHY CPAN is so popular.
I only looked at a handfull of the links. It's sort of a Yahoo! (the original indexer, not todays search engine-cum-kitchen sink) for Python code, which is ok, but check out how one uses CPAN in the real world:I'm sure you can see how this makes CPAN far more useful for building a large repository of useful Perl modules. How, in Python, can you build several layers of libraries that depend on each other without this kind of repository of dependency information? How does a user "come into the know" about these factors?
Of course, that ignores the fact that CPAN modules all come with regression testing and online documentation (installed in the sytem "man" tree) as well.
That said, I think that the idea that comparing LOC in, say, a Red Hat distribution to LOC in CPAN is valuable, regardless of the fact that structure and format are also concerns. They are equally concerns in both environments, and both environments have roughly equal pressures on improving both incrementally over time (e.g. bad code gets migrated away from the core and good code gets migrated in).
ALL OF THAT aside, Perl's CPAN is most valuable not because of its size or the quality of the code, but because it is a repository where thousands of people with highly specialized needs share code with each other. Perl is unique in having created such a space that is widely used outside of core advocates of the language. I don't know why that's the case, but as long as it is, it's a very good thing.
Getting code noticed by your niche's peers and making it available for everyone to use is key to Perl's success as a language.