Software for
Windows is generally uninspired, generically cloned, and overwhelmingly wrought with lackluster (read: lousy) user interfaces. [...] The greatest pieces of software are plagued by unintelligent design, and very few rise to the level of ubiquity"
...is just as true for Linux/X11 desktops and GUI applications. They may have solid software engineering and good features underneath - network transparent file access through KIOslaves in KDE, for example -, but clearly lack innovation, originality, cleverness and great/inspired ideas in the UI interface design.
The vast majority of home computer users wants their operating system to be nothing but a GUI that makes it as easy as possible to run as much software applications as possible in combination with as much hardware as possible. This is the simple reason why Linux is not an option for mainstream home PC users, and won't be any time soon.
Apple's switch to Intel is a perfect example of the traps of closed source. If MacOS X and its applications were free software like GNU/Linux, the architecture switch from PPC to x86 would be almost a no-brainer. Users don't have to wait for companies to distribute new binaries, but can recompile all their software themselves, a freedom that, as it turns out, is essential. After the Bitkeeper fiasco, another example why RMS is right with his categorical opposition to non-free software.
Openoffice is plagued with the same problem that Mozilla had before
it got broken into components, and before Firefox emerged as a fast,
simple, yet sophisticated browser: It's monolithic, slow, has a clunky
UI, and in addition to that is unsexy with no original or compelling
ideas that would set it apart from other Office suites.
As long as this doesn't change, Openoffice won't make a bigger impact
against MS Office than the old Mozilla suite made against MS IE. Given
the messy, bloated, underdocumented and arcane codebase of OOo (which
even includes its own homemade cross-platform GUI toolkit and component
architecture), and, as a result, minimum community involvement in the
development process, I'm afraid this situation won't change any time soon.
Perhaps the Openoffice project should have done the
same with Staroffice that Mozilla did with Netscape - throw away the old
codebase and start from scratch. I'm afraid it's too late for that now.
After all, it took Mozilla seven years to get from its beginnings
to Firefox 1.0. Sun would hardly support such a
massive development effort anyway.
Openoffice 2.0 looks like no genuine improvement, but just cosmetics and
superficial hacks [such as the GTK or Qt widgets on top of the built-in
GUI toolkit] of a rotten codebase.
Unfortunately, AbiWord fails as a lean Firefox-ish alternative to
monolithic OOo - the program is so buggy and unreliable that it's barely
usable.
-F
An ideal world would run on LISP...
on
Practical Common Lisp
·
· Score: 4, Insightful
It's amazing and somwhat sad that programming languages and runtime
environments from Smalltalk to Java to Python to C#/.NET keep
reinventing the wheel while a language from the 1950s has it all and
does it even better - the most elegant syntax thinkable, powerful
paradigms for code reuse, dynamic typing, modern memory management with
no buffer overflows, and, with Common Lisp, one robust,
industrial-strength language with a rich standard library that can both
interpreted and compile code, obsoleting the difference between
"programming" and "scripting" languages.
The initial vision of the GNU system - remember "GNU's not Unix" - was
to combine a kernel written in C for performance reasons with a userland
written largely in LISP. Emacs is the only remnant of that idea, isn't
even LISP in its program core, and uses its own LISP dialect instead of
CLISP or Scheme. [The climacs project, a
CLISP reimplementation of Emacs, tries to fix that.]
Two years ago, I saw a practical demonstration of a Symbolics LISP
Machine from 1987. It was like seeing the light of the holy hacker grail
- the first system whose userland was superior to commandline Unix in
every aspect [Plan9 has superior kernel design to Unix/BSD/Linux, but
its mouse-centric userland sucks IMHO]. Everything was in one language,
syntax and namespace. You could hack and debug the kernel (written in
LISP, too) while it was running [!], the commandline userland hooked
into every aspect of the system, and could be endlessly and seamlessly
extended it just through custom LISP functions and eval-ing them.
Let's dream and hope that perhaps in one or two decades, when insight
into the limitations of the Unix paradigm has become common sense, we
will have a free Lisp OS as the next iteration of Free Software
computing...
Dresden used to be the area where East German computers and chips (more or less illegimate clones of the IBM PC and the Intel 8080/8086 running a Russian clone of DOS) were produced before 1989. Afterwards, the state government invested into maintaining computer and chip production there and bring it to Western level, and AMD was attracted also by the fact that there was a skilled workforce available in the Dresden area which needed no fundamental retraining for modern chip manufacturing.
> Considering what has transpired, the obvious > choice is subversion:)
This would rather surprise me because svn doesn't support distributed repositories and branches which are necessary to maintain the different kernel branches.
Has anyone managed to play it under Linux? I had no luck with mplayer, xine, vlc and the newest w32codecs. The best thing I get is the sound and
error messages "[svq3 @ 0xb32f36ec]error in B-frame picture id".
The bounty is a first good step, but the Gnome project will have to go much deeper to get rid of its bloat.
Remove all deprecated libraries from the codebase of the Gnome core.
In its history, Gnome has changed its libraries and subsystems several times, from imlib to gdk-pixbuf, from gnome-canvas to pango, from Corba to Bonobo to possibly Mono, from esd to gstreamer, and so on. Many Gnome apps still use older, deprecated libraries. Get rid of those libraries and port all apps to the standard core API.
Remove or replace subsystems which never really were useful
I'm thinking of Bonobo and gnome-vfs here which are not consistently used in Gnome and whose quality and use value is questionable. If their functionality is still needed, it could be replaced by KDE's superior kioslaves and kparts (just as KDE is ditching its arts sound demon in favor of gstreamer)
Make all demons optional
Neither Gnome, nor KDE applications should be depending on any desktop-specific userspace demons. Make it possible to deactivate gconf, for example, and have applications read and write configuration files the classical Unix way, by one central switch. Make the sound demon optional, so that audio output could just be written (in old-fashioned, non-overlapping way) to/dev/dsp.
Etc.etc. The demons might have some use for some people, for for many, they are just bloat and unnecessary complexity.
Yeah, I know that all would be a Herculean effort. Probably, it makes more sense to start with a lean and clean codebase like XFCE and just bring its usability to Gnome level, instead of cleaning up a bloated mess...
I hope Knoppix developers implement file storage of a modified installation in a sensible way, i.e. without automatic detection and usage of the user file on system startup, and possibly with user/password fingerprinting. Otherwise, Windows malware could be written that creates manipulated Knoppix system files on hard disks and takes over once somebody boots a Knoppix CD on the machine.
...that the FSF honors a developer who releases his work under a non-copyleft (=the BSD) license and whose main project is an operating system alternative to GNU and Linux.
a digital camera guide, implemented in that non-open binary
annoyance called Flash, gets Slashdot coverage,
and one week ago, my story submission about a
newly released Guide
to Open Content Licenses got rejected?
Not only that the latter covers a subject that should be more relevant
to Slashdot's readership, not only that it is likely the very first
comprehensive guide of its kind, but it's also available as open
standard XHTML + a downloadable PDF file, and released under a Creative
Commons license.
Florian (admittedly involved in creating the Open Content guide, and a
Slashdot member since ca. 1998)
Well, then... GnuStep seems to recommend WM as the choice for Gnustep applications, but isn't itself Gnustep in any way.
The answer is simple: Window Maker is a mockup of the original NextStep desktop look'n'feel, but doesn't use any OpenStep/Gnustep/Cococa libraries or programming paradigms - just like fvwm95 superficially looks like Win95/98, but implements nothing of the underlying Windows API/framework, an infinitely more complex effort pursued, for example, by WINE. So GNUstep is not a window manager, but a free implementation of the entire OpenStep class library framework. Because it doesn't have a window manager of its own yet (i.e. a program that draws window decorations and makes windows movable and resizable), it recommends Window Maker for that task.
It's a pity that, at the peak of the Linux desktop hype in the late 1990s, when evangelists predicted the near death of Microsoft, KDE and Gnome were rushed out of the door, and GNUstep development remained obscure. It was the first time that distributed free software development defected from its proven practice of implementing standardized, proven APIs and technology (like POSIX) and created major APIs of its own. The result is that KDE and Gnome have created APIs that nobody uses for serious large-scale software development projects [except those companies who have large investments into KDE/Gnome themselves, like Ximian with Evolution]. Now KDE and Gnome have a long way to go to clean up and standardize their APIs (via freedesktop.org), usability (via UI guidelines) and code, solving issues that adherence to an existing open GUI specification like OpenStep would have prevented in the first place.
Imagine the massive development efforts on KDE and Gnome, including the massive rewrites of their codebases, would instead had gone into GNUstep, so that the GNU/Linux and *BSD desktop would be OS X/Cocao source compatibile today [and companies developing for OS X port their software to Linux basically with one more compiler run]...
In which areas would you say is Plan9 (still) ahead of Linux/GNU and *BSD, the two operating systems which represent the most contemporary iteration of the original Unix design?
In fact, the Openoffice XML format has already been submitted as the
base of an open XML-based standard for office documents not to ISO, but
to OASIS, see the
coverage in Wikipedia. A draft version of the OASIS Open Office XML
format already exists, and once the official version 1.0 is out, both
Openoffice (the program) and other free software office suites such as
KOffice will switch to it as their native file format (as covered, for
example, in this Linux
Journal article).
Making the OASIS Open Office XML format also an ISO standard would surely be nice and
make it look better on paper to corporate and institutional IT managers.
But for the EU, the current standardization process through OASIS should
be good enough, since the question is whether controlling the format by two
standards bodies at the same time will be technically feasible at all.
No offense, but that's spoken exactly like someone who has no idea what a desktop
environment is.
No offense, but you replied exactly like someone who has no idea what
XFCE is.
Gnome is 90% the application libraries that manage inter-process data, configuration,
internationalization, accessibility, theming, common invocation semantics, error
reporting, etc, etc.
Almost half of what you mention (configuration, internationalization,
theming) is GTK stuff, not Gnome. And those aspects managed by Gnome are
used by only very few programs. Most so-called Gnome applications,
like The Gimp, are in fact GTK applications and have no Gnome
bindings. Of those programs linking to Gnome libraries and
middleware (Bonobo, Gnome-VFS, gconf), few if any make full and
consistent use of them.
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.
No, XFCE is an integrated desktop environment which includes a window
manager (xfwm), a panel (xfce-panel) with applets, a file manager
(xffm), a backdrop manager, and a printing manager. All these components
are based on GTK and freedesktop.org standards, like the XDND
drag'n'drop protocol or the wm spec which
also the window managers of KDE and Gnome (kwin and metacity) implement.
XFCE can be fully configured over its own GUI menus, which is
another difference to window managers which aren't really desktop
environments.
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
Well, except that this doesn't work because you will hardly find 20
applications running parallel on your desktop that support gconf. If you
refer to themeing and color settings, this is generic toolkit (GTK) stuff
for which no Gnome is needed. (After all, you can set GTK themes and
colors in XFCE as well.)
want to change all of your applications
to use LCD-friendly font-smoothing
Another shoot in your foot. This is GTK, not Gnome stuff again and can
be set in the XFCE control panel as well.
speak a language that isn't the default (and
perhaps has strange rules like being written backwards)
Again, GTK stuff, not Gnome library stuff at all.
can't see / hear / type /
use a mouse / etc.
Mouse and keyboard settings can be configured within XFCE as well.
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. Check out XFCE to see how you
can implement a DE in about 4 megabytes, running screaming fast on PII
class hardware, that builds on nothing but GTK
and freedesktop.org standards and still is a sufficiently integrated GUI.
Disclaimer: I use neither Gnome, nor KDE, but a radical
console-centric non-desktop setup with the ratpoison window manager, but
nevertheless eagerly follow desktop/GUI development because I want to
see more mainstream adoption of GNU/Linux.
The "new" Gnome IMHO is the first GNU/Linux desktop with a sensible
default configuration and a simple, elegant and pleasant user interface. IMHO,
it's the most pleasant, straightforward and stress-free desktop user
interface available today; better than Windows, better than MacOS X,
almost as good as the classic MacOS 7.x-9.x from which it has learned a
lot. (Most longtime Mac users hate OS X for its flashy, unintuitive and
inconsistent Aqua user interface, and rightly so in my opinion.) I
also like that Nautilus was freed from the sidebar and toolbar bloat of
today's file managers and defaults to spatial view.
On the other hand, I agree with the complaints about dumbed-down
configurability and the horrors of gconf. I prefer KDE 3.x in that it
allows to customize almost any aspect of the GUI directly through GUI
dialogues and not arcane registry-like settings. The solution would be a
desktop that is simple by default, but would have an "advanced settings"
button in every configuration dialogue which then in turn would pop up a
more complex configuration panel. There could be just one central
control panel switch to globally turn the "advanced settings" buttons on
or off in all dialogue boxes. (And it could be set to "off" for the
default vanilla desktop setting.)
There could be two ways to approach this:
Gnome creates the "advanced settings" switch and wraps all gconf
options into extended configuration dialogue boxes.
KDE does the same from the reverse angle by thoroughly cleaning up
and streamlining its user interface,
putting all expert settings into separate "advanced settings" dialogues.
My real annoyance with Gnome is the discrepancy between its lean
surface and its crufty and bloated code under the hood. I find it quite
shocking to run memstat and see how many megabytes of RAM are eaten up
by Gnome's components, with trivial panel applets that shouldn't consume
more than a few kilobytes eating several megabytes, or the x86
executable of such a simplistic window manager as metacity taking up
half a megabyte whereas desktop environments like XFCE show
that the same can be done with a fraction of the resource usage.
While KDE has a lot of code, too, its abstraction layers - like
kioslaves, vfs, kparts - are actually used by K applications. In Gnome,
comparable subsystems exist only in a half-broken state of
competing, incompatible APIs (imlib2 vs. gdk-pixbuf, Corba vs. Bonobo
vs. Mono, gnome-canvas vs. GtkGLArea etc.) that are not even
consistently used at all in so-called Gnome applications.
The truth probably is that all these either KDE/Qt or Gnome/GTK specific
layers/APIs/subsystems will be eventually replaced by common freedesktop.org
standards and partly also improvements of the X.org X11 implementation
through the work of Keith Packard and others. It would be a worthy goal
for a Gnome 3.0 to eliminate all cruft in its code, standardize on one
API for each subsystem, kick out broken layers and APIs to replace them
with freedesktop.org's solutions (d-bus, mimedb), or, where technically
feasible, KDE's proven solutions (kioslaves).
While choice and competing designs and implementations are generally
good, some fundamental standardization of the GNU/Linux desktop
is is necessary to allow the whole operating system to be
configured and administrated over the desktop. Developers of system
components such as bootloaders, MTAs, packet managers etc. need desktop
standardization so that they can write GUI control panels which work
on all desktops. Without that, GNU/Linux desktops remain relatively
abstract, high-level shells, and free operating systems can only be run
by people who either are commandline professionals themselves, or have
knowledgable system administrators to help them out.
I realize RMS has good intentions but I don't see any point to this.
It's a BIOS. What good would making it GNU/BIOS do?
I wonder how this could be moderated insightful. The proprietary
nature of BIOSes severely cripple the usefulness of PCs today and
destroys their long-term value because support of modern modern hardware
features doesn't get backported to BIOSes of older PCs. Some examples:
The nightmare that is ACPI and its support under free OSes could be
fixed with free BIOS/firmware replacements
Hardly any BIOS supports booting from USB devices (external
drives or USB memory sticks), this could be easily fixed as well
A free BIOS/firmware could implement a generic way of
booting computers from the network, without the need of onboard boot
ROMs (and proprietary net boot schemes) in Ethernet adapters
A free BIOS/firmware could even implement interfaces to access and set up the BIOS
remotely via network or serial consoles. This would remove a big
showstopper that makes x86 commodity hardware with Linux/*BSD still inferior to
the proprietary RISC/Unix systems of Sun et.al.
Older BIOSes (for Pentium I/II/K6 motherboards) don't recognize
harddisks above 30 GB, forcing owners to throw away hardware that can
would still perform reasonably under Linux or *BSD.
Other older BIOSes don't support booting from CD, thus making
OS installations or use of rescue CDs difficult
The quality of IRQ management and fine-tuning options for hardware
parameters, for example, vastly differs between current BIOS implementations, getting
a good BIOS is thus a lottery.
A generic, free BIOS/firmware could thus
(a) bring BIOSes to new, desirable levels of functionality [see above],
make (b) BIOS user interfaces consistent across heterogenous
computers, and (c) finally allow consumers to choose motherboards based on hardware
quality only.
Simply put - No, the CCL prohibits commerical re-use, which is
something that we do not want to prohibit.
No, it's not correct the way you phrase it. Creative Commons doesn't
provide one, but multiple Licensing options. Depending on which exact
Creative Commons license you choose, you can either allow or prohibit
commercial reuse.
Wikipedia's entire content and submissions are licensed under the GNU
Free Documentation License (FDL). This license is considered problematic
by some people in the free software community because it allows
either the author or future editors to put invariable sections into a
document. Do you share these concerns? Could somebody, theoretically,
fork off a version of Wikipedia "enhanced" with invariable, i.e.
proprietary, content?
I understand that there were not any good alternatives to the GNU FDL when
Wikipedia was started. But would you rather pick a Creative Commons
license for the project today?
Avoid GUIs, choose a tranquil "anti-desktop"
on
Handling Eye-Strain?
·
· Score: 2, Informative
I had the same problem as you. The major source of visual stress and
annoyance are GUI desktops with their multiple color, countless
toolbars, flashy icons, blinking & popping up messages.
My solution grew over years switching from Window Maker (1998) to 9wm
(1999) to larswm (2000) to
ratpoison (2001) and since then
is what a famous
freshmeat editorial calls an "anti-desktop".
Here is the Tao:
Run all windows fullscreen and without decorations with a WM like ratpoison (or Ion or
larswm)
Nothing then distracts you from the program you work in, as opposed to a
typical GUI desktop where diverse window/tool/status bar consume up 50%
of screen estate.
Run CLI/console programs wherever possible.
Since CLI programs all use the same font in only one size, few colors
(which typically can be customized and thus streamlined to a useful
minimum), they offer a visual tranquility that is hard if not
impossible to achieve through theming in
GUIs
I essentially do all my work in a GNU screen session inside
an rxvt, with a couple of open zsh shells plus vim, mutt, elinks, slrn and
aumix.
Choose a good, readable, big console font,
I was dissatisfied with all available choices and designed my own one
called pxl 2000.
I use the large 20 pixel size variant which gives me 92 characters per line
on a 1024x768 pixel display
Use white text on black background
Black backgrounds are the most tranquil backgrounds possible (dark blue
might be an alternative for some people). Since monitors do not reflect
light like paper, but are light sources themselves, using brighter
backgrounds is almost the equivalent of looking into a neon lamp your
entire day. If you use CRTs, black backgrounds also reduce flicker and
radiation.
Use textmode web browsers wherever possible
A major source of visual stress is browsing the web with its flashy and
page layouts that change (and thus constantly force your eyes to
readjust) with every hop from site to site. Textmode browsers like lynx,
w3m, links and elinks streamline the web to one, always consistent page
layout (elinks offers the neat feature of switching table rendering off
on the fly) in your preferred, fixed-size console font, and allow to
concentrate on the real textual information of the web.
Use a dark grey, non-flashy color scheme for the legacy GUI applications
you still need
Configuring GUI applications to black backgrounds and white text
typically creates compatibility problems (i.e. unreadable widgets)
because some application programmers didn't think about such a setup.
So the best compromise is to configure all GUI widgets to a dark grey
background with white menu text. The get color scheme consistenty across
Qt and GTK applications plus Mozilla, create a color scheme in the KDE
Control Center and click the option "Apply to non-KDE applications".
It's grossly underadvertised, but check out the classical BSD program
"remind". It is rock-solid, lean (~100k) and rovides everything you
need, including storage of appointments and alarms and a classical
tabular calendar view on the console with the "-c" switch. Other goodies
are moon phases, sunrise/sunset, Hebrew calendar, PostScript output,
multilingual messages, and support for holidays.
The classical pilot-link package includes a utility for converting
PalmOS calendars to remind syntax.
Slashdot Mirror
The vast majority of home computer users wants their operating system to be nothing but a GUI that makes it as easy as possible to run as much software applications as possible in combination with as much hardware as possible. This is the simple reason why Linux is not an option for mainstream home PC users, and won't be any time soon.
Apple's switch to Intel is a perfect example of the traps of closed source. If MacOS X and its applications were free software like GNU/Linux, the architecture switch from PPC to x86 would be almost a no-brainer. Users don't have to wait for companies to distribute new binaries, but can recompile all their software themselves, a freedom that, as it turns out, is essential. After the Bitkeeper fiasco, another example why RMS is right with his categorical opposition to non-free software.
As long as this doesn't change, Openoffice won't make a bigger impact against MS Office than the old Mozilla suite made against MS IE. Given the messy, bloated, underdocumented and arcane codebase of OOo (which even includes its own homemade cross-platform GUI toolkit and component architecture), and, as a result, minimum community involvement in the development process, I'm afraid this situation won't change any time soon. Perhaps the Openoffice project should have done the same with Staroffice that Mozilla did with Netscape - throw away the old codebase and start from scratch. I'm afraid it's too late for that now. After all, it took Mozilla seven years to get from its beginnings to Firefox 1.0. Sun would hardly support such a massive development effort anyway.
Openoffice 2.0 looks like no genuine improvement, but just cosmetics and superficial hacks [such as the GTK or Qt widgets on top of the built-in GUI toolkit] of a rotten codebase.
Unfortunately, AbiWord fails as a lean Firefox-ish alternative to monolithic OOo - the program is so buggy and unreliable that it's barely usable.
-F
The initial vision of the GNU system - remember "GNU's not Unix" - was to combine a kernel written in C for performance reasons with a userland written largely in LISP. Emacs is the only remnant of that idea, isn't even LISP in its program core, and uses its own LISP dialect instead of CLISP or Scheme. [The climacs project, a CLISP reimplementation of Emacs, tries to fix that.]
Two years ago, I saw a practical demonstration of a Symbolics LISP Machine from 1987. It was like seeing the light of the holy hacker grail - the first system whose userland was superior to commandline Unix in every aspect [Plan9 has superior kernel design to Unix/BSD/Linux, but its mouse-centric userland sucks IMHO]. Everything was in one language, syntax and namespace. You could hack and debug the kernel (written in LISP, too) while it was running [!], the commandline userland hooked into every aspect of the system, and could be endlessly and seamlessly extended it just through custom LISP functions and eval-ing them.
Let's dream and hope that perhaps in one or two decades, when insight into the limitations of the Unix paradigm has become common sense, we will have a free Lisp OS as the next iteration of Free Software computing...
Dresden used to be the area where East German computers and chips (more or less illegimate clones of the IBM PC and the Intel 8080/8086 running a Russian clone of DOS) were produced before 1989. Afterwards, the state government invested into maintaining computer and chip production there and bring it to Western level, and AMD was attracted also by the fact that there was a skilled workforce available in the Dresden area which needed no fundamental retraining for modern chip manufacturing.
> choice is subversion:)
This would rather surprise me because svn doesn't support distributed repositories and branches which are necessary to maintain the different kernel branches.
Has anyone managed to play it under Linux? I had no luck with mplayer, xine, vlc and the newest w32codecs. The best thing I get is the sound and error messages "[svq3 @ 0xb32f36ec]error in B-frame picture id".
Anyone remember the time when he worked on an Alpha?
- Remove all deprecated libraries from the codebase of the Gnome core.
- Remove or replace subsystems which never really were useful
- Make all demons optional
Yeah, I know that all would be a Herculean effort. Probably, it makes more sense to start with a lean and clean codebase like XFCE and just bring its usability to Gnome level, instead of cleaning up a bloated mess...In its history, Gnome has changed its libraries and subsystems several times, from imlib to gdk-pixbuf, from gnome-canvas to pango, from Corba to Bonobo to possibly Mono, from esd to gstreamer, and so on. Many Gnome apps still use older, deprecated libraries. Get rid of those libraries and port all apps to the standard core API.
I'm thinking of Bonobo and gnome-vfs here which are not consistently used in Gnome and whose quality and use value is questionable. If their functionality is still needed, it could be replaced by KDE's superior kioslaves and kparts (just as KDE is ditching its arts sound demon in favor of gstreamer)
Neither Gnome, nor KDE applications should be depending on any desktop-specific userspace demons. Make it possible to deactivate gconf, for example, and have applications read and write configuration files the classical Unix way, by one central switch. Make the sound demon optional, so that audio output could just be written (in old-fashioned, non-overlapping way) to /dev/dsp.
Etc.etc. The demons might have some use for some people, for for many, they are just bloat and unnecessary complexity.
I hope Knoppix developers implement file storage of a modified installation in a sensible way, i.e. without automatic detection and usage of the user file on system startup, and possibly with user/password fingerprinting. Otherwise, Windows malware could be written that creates manipulated Knoppix system files on hard disks and takes over once somebody boots a Knoppix CD on the machine.
...that the FSF honors a developer who releases his work under a non-copyleft (=the BSD) license and whose main project is an operating system alternative to GNU and Linux.
- a digital camera guide, implemented in that non-open binary
annoyance called Flash, gets Slashdot coverage,
- and one week ago, my story submission about a
newly released Guide
to Open Content Licenses got rejected?
Not only that the latter covers a subject that should be more relevant to Slashdot's readership, not only that it is likely the very first comprehensive guide of its kind, but it's also available as open standard XHTML + a downloadable PDF file, and released under a Creative Commons license.Florian (admittedly involved in creating the Open Content guide, and a Slashdot member since ca. 1998)
The answer is simple: Window Maker is a mockup of the original NextStep desktop look'n'feel, but doesn't use any OpenStep/Gnustep/Cococa libraries or programming paradigms - just like fvwm95 superficially looks like Win95/98, but implements nothing of the underlying Windows API/framework, an infinitely more complex effort pursued, for example, by WINE. So GNUstep is not a window manager, but a free implementation of the entire OpenStep class library framework. Because it doesn't have a window manager of its own yet (i.e. a program that draws window decorations and makes windows movable and resizable), it recommends Window Maker for that task.
Imagine the massive development efforts on KDE and Gnome, including the massive rewrites of their codebases, would instead had gone into GNUstep, so that the GNU/Linux and *BSD desktop would be OS X/Cocao source compatibile today [and companies developing for OS X port their software to Linux basically with one more compiler run]...
In which areas would you say is Plan9 (still) ahead of Linux/GNU and *BSD, the two operating systems which represent the most contemporary iteration of the original Unix design?
Making the OASIS Open Office XML format also an ISO standard would surely be nice and make it look better on paper to corporate and institutional IT managers. But for the EU, the current standardization process through OASIS should be good enough, since the question is whether controlling the format by two standards bodies at the same time will be technically feasible at all.
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. Check out XFCE to see how you can implement a DE in about 4 megabytes, running screaming fast on PII class hardware, that builds on nothing but GTK and freedesktop.org standards and still is a sufficiently integrated GUI.
The "new" Gnome IMHO is the first GNU/Linux desktop with a sensible default configuration and a simple, elegant and pleasant user interface. IMHO, it's the most pleasant, straightforward and stress-free desktop user interface available today; better than Windows, better than MacOS X, almost as good as the classic MacOS 7.x-9.x from which it has learned a lot. (Most longtime Mac users hate OS X for its flashy, unintuitive and inconsistent Aqua user interface, and rightly so in my opinion.) I also like that Nautilus was freed from the sidebar and toolbar bloat of today's file managers and defaults to spatial view.
On the other hand, I agree with the complaints about dumbed-down configurability and the horrors of gconf. I prefer KDE 3.x in that it allows to customize almost any aspect of the GUI directly through GUI dialogues and not arcane registry-like settings. The solution would be a desktop that is simple by default, but would have an "advanced settings" button in every configuration dialogue which then in turn would pop up a more complex configuration panel. There could be just one central control panel switch to globally turn the "advanced settings" buttons on or off in all dialogue boxes. (And it could be set to "off" for the default vanilla desktop setting.)
There could be two ways to approach this:
My real annoyance with Gnome is the discrepancy between its lean surface and its crufty and bloated code under the hood. I find it quite shocking to run memstat and see how many megabytes of RAM are eaten up by Gnome's components, with trivial panel applets that shouldn't consume more than a few kilobytes eating several megabytes, or the x86 executable of such a simplistic window manager as metacity taking up half a megabyte whereas desktop environments like XFCE show that the same can be done with a fraction of the resource usage. While KDE has a lot of code, too, its abstraction layers - like kioslaves, vfs, kparts - are actually used by K applications. In Gnome, comparable subsystems exist only in a half-broken state of competing, incompatible APIs (imlib2 vs. gdk-pixbuf, Corba vs. Bonobo vs. Mono, gnome-canvas vs. GtkGLArea etc.) that are not even consistently used at all in so-called Gnome applications.
The truth probably is that all these either KDE/Qt or Gnome/GTK specific layers/APIs/subsystems will be eventually replaced by common freedesktop.org standards and partly also improvements of the X.org X11 implementation through the work of Keith Packard and others. It would be a worthy goal for a Gnome 3.0 to eliminate all cruft in its code, standardize on one API for each subsystem, kick out broken layers and APIs to replace them with freedesktop.org's solutions (d-bus, mimedb), or, where technically feasible, KDE's proven solutions (kioslaves).
While choice and competing designs and implementations are generally good, some fundamental standardization of the GNU/Linux desktop is is necessary to allow the whole operating system to be configured and administrated over the desktop. Developers of system components such as bootloaders, MTAs, packet managers etc. need desktop standardization so that they can write GUI control panels which work on all desktops. Without that, GNU/Linux desktops remain relatively abstract, high-level shells, and free operating systems can only be run by people who either are commandline professionals themselves, or have knowledgable system administrators to help them out.
I wonder how this could be moderated insightful. The proprietary nature of BIOSes severely cripple the usefulness of PCs today and destroys their long-term value because support of modern modern hardware features doesn't get backported to BIOSes of older PCs. Some examples:
A generic, free BIOS/firmware could thus (a) bring BIOSes to new, desirable levels of functionality [see above], make (b) BIOS user interfaces consistent across heterogenous computers, and (c) finally allow consumers to choose motherboards based on hardware quality only.
The "Choose License" page defaults to "Allow commercial uses of your work", btw.
-F
I understand that there were not any good alternatives to the GNU FDL when Wikipedia was started. But would you rather pick a Creative Commons license for the project today?
My solution grew over years switching from Window Maker (1998) to 9wm (1999) to larswm (2000) to ratpoison (2001) and since then is what a famous freshmeat editorial calls an "anti-desktop".
Here is the Tao:
Nothing then distracts you from the program you work in, as opposed to a typical GUI desktop where diverse window/tool/status bar consume up 50% of screen estate.
Since CLI programs all use the same font in only one size, few colors (which typically can be customized and thus streamlined to a useful minimum), they offer a visual tranquility that is hard if not impossible to achieve through theming in GUIs
I essentially do all my work in a GNU screen session inside an rxvt, with a couple of open zsh shells plus vim, mutt, elinks, slrn and aumix.
I was dissatisfied with all available choices and designed my own one called pxl 2000. I use the large 20 pixel size variant which gives me 92 characters per line on a 1024x768 pixel display
Black backgrounds are the most tranquil backgrounds possible (dark blue might be an alternative for some people). Since monitors do not reflect light like paper, but are light sources themselves, using brighter backgrounds is almost the equivalent of looking into a neon lamp your entire day. If you use CRTs, black backgrounds also reduce flicker and radiation.
A major source of visual stress is browsing the web with its flashy and page layouts that change (and thus constantly force your eyes to readjust) with every hop from site to site. Textmode browsers like lynx, w3m, links and elinks streamline the web to one, always consistent page layout (elinks offers the neat feature of switching table rendering off on the fly) in your preferred, fixed-size console font, and allow to concentrate on the real textual information of the web.
Configuring GUI applications to black backgrounds and white text typically creates compatibility problems (i.e. unreadable widgets) because some application programmers didn't think about such a setup. So the best compromise is to configure all GUI widgets to a dark grey background with white menu text. The get color scheme consistenty across Qt and GTK applications plus Mozilla, create a color scheme in the KDE Control Center and click the option "Apply to non-KDE applications".
-F
The classical pilot-link package includes a utility for converting PalmOS calendars to remind syntax.