The German computer magazine c't just tested the brandnew G4-based Apple XServe w/ OS/X against a comparatively cheap Dell rackmount server with a PIII(!)/1.4 GHz running on RedHat Linux. Result: The Dell smoked the XServe in regards to both software and hardware performance.
It turned out that even a Pentium III chip w/ PC133 SDRAM is faster than a G4, and that the G4 is only half as fast in memory writes. Try to scale this up to a comparison of Apple's hardware against a 2.5 GHz-P4 or P4-Xeon with RDRAM, and you see that Apple and Motorola are lagging 1-2 years behind in performance. I imagine that Apple's management is highly nervous about the situation. The more time will pass by, the lesser are the chances to cloud the problems of the PPC platforms with marketing rhetoric.
Apple sells the myth of G4 performance superiority with Photoshop benchmarks, thus convincing the gullible and non-technical people. Photoshop indeed performs better on a Mac because it is optimized for the platform; the Wintel version of Photoshop is only a port of the Mac version, using an API compatibility layer and lacking CPU optimization.
The only real advantage of the PPC at the moment is that it lacks a lot of backwards compatibility cruft and, because of its RISC design, consumes less power and spreads less heat. It is a fine notebook CPU (and Apple is a fine notebook manufacturer). But Apple seems to have had no other chance but giving up this advantage by selling its newest line of desktop G4 Macs with dual CPUs, keeping up with Intel at least halfway with such a "hack".
I couldn't think of a project that has done more for the advancement of free software (in practical terms) than Debian. The years of continuous good work seem to pay off now. While RedHat is popular among corporate customers, Mandrake (and, in Europe: SuSE) among newbie users and people who boot into GNU/Linux only occasionally,
it seems as if Debian is becoming the de facto standard distribution of non-corporate advanced users (who typically pick Debian as their second distribution and then stick with it). As a genuinely free distribution, Debian is also much appreciated in education; my university, for example, hosts its own Debian FTP mirror.
While Debian's Free Software-only politics was controversial some years ago - anyone remember the ugly term "Debian Nazi"? -, it no longer seems so due to DMCA, patenting, and perversions of copyright. Debian has done invaluable work for the Free Software community by thoroughly reviewing the licensing of the software it ships, freeing users from the hassle to become legal experts.
Debian users enjoy both the technical excellence and the legal safety of running Debian "main".
It would be good if the FSF Award were given to Debian to finance work on the new Debian installer. This is the last showstopper piece which prevents massive newbie user adoption of this distribution.
Any chance to underclock this beast at, say, 1.4 GHz w/ passive cooling? (Would still fulfill my computing needs.)
But really, what a waste of electricity, heat, and what a noise pollution. I'm waiting for desktop CPUs with SpeedStep which clock down to 100 MHz when you're doing vi editing and go up to 2.8 GHz, turning on all fans, when you compile software or transcode video streams.
I hope there will be enough consumer demand for such CPUs, pushing AMD/Intel towards saner technology.
...and that's why Microsoft is switching its business model from selling boxed sets to subscription services. This already is the case here in Europe where corporate/public service/campus licenses of Microsoft programs expire after 24 months (don't know about the US).
With tying future Windows releases to.NET-based services, Microsoft will be able to charge much less for the installed OS, but get their revenue on subscription fees and by charging for each extra feature/service a user decides to employ.
ESR's rhetoric is uninformed and makes the Free Software/Open Source community look stupid. Besides, the recent troubles of Linux kernel development show that the "Bazaar" model has
its limitations/doesn't scale. As soon as a project has gained a certain size and complexity, you inevitably need centralized structures (see XFree86, FreeBSD, gcc, libc, Emacs, Mozilla...).
If Free Software/Open Source doesn't want to be (wrongly) put in the same bag as the dotcom bubble rhetoric of 1996-1999, it should dissociate itself
from the rhetoric bubbles of ESR.
Has anyone actually read their documentation?
on
OpenPKG 1.0 Released
·
· Score: 4, Informative
If you had, then you would know that
it uses a modified, incompatible version of rpm which will will coexist with "normal" rpm in case the OS it includes the latter. (Unfortunately, the OpenPKG executable is called "rpm" as well, but resides in a different path)
it builds its own repository/package database separate from the core OS packages
it uses its own particular filesystem layout
it doesn't provide apt-like functionalitySo OpenPKG does not replace existing package systems, but is meant as a secondary package system for OS-independent userspace tools (thus allowing to share installed packages across different Unix-like OSs).
It breaks all Unix/Linux filesystem/compatibility standards, creates headaches by installing itself as a secondary package manager/database, and thus is unlikely
to be widely adopted. (Seems rather like a possible solution for sysadmins who want consistent application installations acrosses different flavors Linux/FreeBSD/Solaris).
Re:Messing things up or using Perl for what it fit
on
Perl6 for Mortals
·
· Score: 2
elflord wrote:
If you don't use it for "general programming purposes", you're not in much of a position to make such a judgement.
Who says I didn't? I tried and decided that others languages fit that purpose better.
It's disingenious to call the OO support in perl a "more esoteric feature" of the language
Who says I referred to OO support as an "esoteric feature"? While I think that other languages are more fun to use for OO, the "esoteric features" in Perl I meant is everything that makes Perl syntax terse, obfuscated and hardly readable for everyone but the original programmer. The Perl6 code snippets I saw don't exactly seem to improve that situation.
Perl allows coding styles so different that two Perl programs may look as if they were written in entirely different languages. Perl6 seems to further this balkanization. This is why I consider Perl the wrong tool for large projects involving many programmers. (Imagine a Mozilla, Emacs or KDE written in Perl - shudder...)
Messing things up or using Perl for what it fits
on
Perl6 for Mortals
·
· Score: 3, Troll
It's not only the Perl6 code examples which look scary, most Perl code that uses advanced/obscure features already does. I am a Perl coder, but I have a hard time reading much Perl5 code out there. Perl6 seems to make things worse.
The bottom line is that Perl is simply not the right tool for general programming purposes. I only use Perl as what it was originally intended to be - a "practical extraction and report generation language" that excels at scanning and computing huge amounts of text, as an integrated, improved replacement of the classical shell/sed/awk/grep etc. toolchain. Perl code can be readable and maintainable if it's written in C style and deliberately excludes the more esoteric features of the language. For anything else, and any "serious" - i.e. complex - programming, pick C/C++ or Python. It is no contradiction for me to concede this and still be a Perl afficionado.
Don't FreeBSD and MacOS X also use gcc and other GNU software? Why aren't we forced to call them GNU/FreeBSD and GNU/MacOS X?
But unlike in mainstream "Linux Distributions", gcc is the only major GNU component. The libc and toolsets (cat, tar etc.) of the BSDs are non-GNU, same goes for the standard shells.
Linux, the kernel, does not amount to a functional operating system on its own. To have a minimal running system, you need a libc, an ld linker, the basic cp/cat/mv... tools and a shell. All major "Linux distributions" - as well as the Linux Standard Base specification - use the Linux+GNU setup for the core OS. (While XFree86, Apache, KDE, Gnome, Samba, etc. are optional components.) So its fair, IMHO, to speak of "GNU/Linux" when we refer to the working operating system (or, if you prefer, the lowest common denominator of the operating system).
Better don't compare Win2k and GNU/Linux in terms of RAM/resource usage when it comes to deployment on the desktop. Win2k may eat more RAM initially, but any realistic desktop GNU/Linux installation struggles with the different library/component sets to be loaded at once. Just take the article as an example:
the KDE desktop loads Qt2.x (a very big toolkit) + its own rich set of shared libraries (kdeinit, dcop, khtml etc.etc.)
StarOffice is built around its own heavyweigt cross-platform C++ toolkit which it loads into memory
The Gnome software loads GTK (not exactly a small toolkit) + its own big set of libraries.
This not only creates issues of look'n'feel consistency and interoperability (to mention only drag'n'drop...), but since all these libraries duplicate functionality of their counterparts,
they result in a bloated "Linux Desktop". One might argue that RAM is cheap, but increased load times really suck. While I used to have reservations towards KDE because of its initial licensing issues and seeming bloat, it is seems more and more as if it is the only professional, well-crafted free X11 desktop environment & component architecture (aside from GNUstep which doesn't get off the ground), so I hope that KDE becomes the unified standard API for desktop applications & overcomes the fragmentation and inefficiency on the GNU/Linux desktop.
better responsiveness under heavy load - Linux 2.4.x with its VM problems is particularly bad in comparison
smaller base software/dependencies; BSD libc is much smaller than glibc;/bin/sh points to ash, so all shell and system scripts are ash processes (and not bloated bash processes); classic Unix tools are less heavyweight than GNU tools (Remember: you can use GNU tools, bash etc., but they're not a dependency)
mature device file system
Clear separation of what belongs to the core OS & third party software (=ports system)
Best package management for installing/compiling from source (Debian's apt-get src isn't there yet)
Kernel features are fewer, but proven & tested (as opposed to many experimental or not-yet-mature drivers/subsystems/filesystems in Linux)
standard file system is 64 bit, allowing big single files
Package selections show that FreeBSD maintainers are real Unix afficionados (vim 6.0 available etc.)
the whole system is/feels very solid and mature
What I dislike:
distribution/ports mixes free and non-free software (Motif etc.) without prompting the user what is free and not; bad not only for Free Software zealots, but also for people who want to make sure they can use software without limitations in their environment (FreeBSD looks as it is made by people for whom software freedom is a secondary concern)
available for a smaller no. of hardware architectures than Linux (or use NetBSD on non-x86 platforms, but that's already a different OS)
no journalling filesystems (no ReiserFS, no XFS), a very small number of filesystems supported
no/proc, no framebuffer device, no ALSA sound drivers, no hardware accelerated graphics in the kernel
much worse SMP support than current Linux kernels
. GNU/Linux feels more "modern" than FreeBSD, while FreeBSD is comparatively "conservative", but also more solid. Draw your own conclusions.
what do you want to be changed in KDE? what do u hate about KDE? what do you like? What do you think should be improved? What do you think should be removed?
Now that KDE has reinvented itself and acquired great new functionality with release 2.0 and greatly stabilized the new architecture with 2.1 and 2.2, I hope KDE developers focus not so much on new features, but on making the existing code & user interface snappier and easier to use.
Here are some ideas:
Improve overall responsiveness, i.e. decrease load times, memory usage, etc. I understand that a lot of work is being done in this direction - which is very good (as opposed to Gnome, SCNR) -, but KDE still isn't there.
Configuration/setting menus are still confusing for newbies and experienced users alike because they're spread over many menus (especially in konqueror) and sometimes seem to be part of the application, sometimes part of the configuration center.
Interface redundancies (i.e. multiple menu methods for the same functions) are also confusing, or it should at least be possible to turn them off. (It would be great if right-click context menus could be turned off, for example.)
Allow to configure KDE as a web browser-centric desktop without the classical floating windows + launchbar paradigm. It is already possible to start X11 with konqueror as the window manager (put exec konqueror into.xinitrc), run it full-screen and access applications only as konqueror-embedded parts. (Like the konqueror-embedded terminal, for example.) Hardly anyone has realized how f***ing great this is! I know many computer-newbie user who can handle the Web, but can't handle classical WIMP GUIs, and prefer web-based applications simply because they find them easier to use. With konqueror as a framework for browser-based/-embedded applications, GNU/Linux could make real inroads into desktop computing! (You sell people a computer that "as simple to use as a web browser".)
For people like me: Allow to toggle icon buttons with text buttons
And, finally: Create a framework that maps the shell/console onto the desktop. Imagine GUI wrappers for all classical Unix console applications (grep, cat, sed, find...) which allow to toggle options by GUI menus AND build pipes GUI-style, i.e. by dragging pipes between icon representations of command-line tools with the mouse. Steal from visual programming environments (like MAX or, available for GNU/Linux, PD) to achieve this.
Remember that Alan Kay/Xerox PARC invented the GUI to make average users capable of programming, and that Apple & Microsoft left out half of the concept when they brought it to mainstream computing. Free Software should do better here.
People in the U.S. might not know this, but British computer manufacturer Amstrad produced an updated sort-of-clone of the TRS-80, the Notepad NC-100/200. Similar to the Tandy, it's a book-/papersize computer with a full-size keyboard and a 8 lines x 80 chars LCD display, serial (9600 baud) and parallel interfaces, built-in text editor, terminal program (with X-Modem file transfer) and BASIC, and it runs 12 hours on four AA batteries. Unlike the Tandy, it has 64k RAM (of which 59k can be used for documents), a PCMCIA slot for SRAM memory cards (up to 1 MB), all the while being thinner and lighter than the TRS-80 (about 1lbs). Check out this site and the Amstrad Notepad Users' Web for the gory details. The NC-200 model is equipped with more RAM, a DOS-compatible floppy drive and a bigger LCD, but I never saw one of those machines. I bought my NC-100 about 7 years ago for $80 (new), an excellent technical handbook was included.
I own both the Tandy (in its European Olivetti-branded variant) and the Amstrad. The big plus of the Tandy are the display and the keyboard. Technically, the Amstrad is better - especially with a PCMCIA SRAM card -, and its much lower weight is also a big plus. I recently bought a foldable keyboard for my Palm, but found it a much less reliable and practical solution than the Armstrad.
Reading through the LSB specification, I am disappointed that it prescribes the "fat" GNU implementations of standard Unix tools as a minimum requirement for compliance. Of course I'm all in love with the added functionality of the GNU tools, I just think it's wrong to make them "standard", i.e. a dependency.
Examples:
The standard LSB shell is bash,
the standard LSB tar is GNU tar (with the -z option and others).
Making them a standard requirement rules out more lightweight implementations, such as the ash shell and the busybox or the BSD tools. This in turn makes it impossible to build embedded Linux systems conforming to the LSB - be it PDA Linux or be it one-disk routers.
Instead of targetting only server/workstation setups, I would have preferred the LSB to settle on low common denominators, like
the common POSIX-compliant functional subset of ash and bash,
the common subset of GNU tar, BSD tar and busybox tar, etc.etc..
This would still allow anyone to make bash the standard shell and GNU tar the standard tar in an LSB-compliant distribution, but it would require third-party software makers to take care that their shell scripts run on ash as well as on bash if they want the LSB compliance sticker for their product.
(P.S.: That said,
I would love to see GNU/Linux distributions - above all: Debian - to scale down to a basic ash/busybox setup, which would require [a] to get rid of bash/GNU tool specific syntax in the setup and configuration scripts, [b] free all their package managing from dependencies on scripting languages like Perl, using ash scripts + minimal sed + minimal awk for simple tasks and compiled C code for more complicated stuff.)
IMHO, antiword is by far the best Word-to-Ascii converter out there. It even renders footnotes, can be used in pipes and is much faster than wvWare. The program is GPL and comes for a variety of OS platforms. As the moderator of a mailing list, I regularly use it to convert *.doc attachments. (One should patch majordomo so that it automatically filters *.doc attachments through antiword. It has worked flawlessly for me since more than a year.
It surprises me quite a lot that such a superb program is so litte known in the Free Software community.
What if web masters manipulate the spider and return false search results (for luring people into pr0n, spam, propaganda...)?
The grub concepts sounds good, but I doubt it will stand reality unless you create a complex "web of trust" system. (Which in turn would be too complex for grub to become popular.)
In stressing the difference between kernel+distribution (Linux) and complete OS (FreeBSD), BSD advocacy makes it difficult to actually compare features. At least if you stick to open source software, both Linux and *BSD run the same userland (or can be customized to that point). But what about the kernels?
Some advantages of *BSD kernels I can think of
Better reponse under high network load
Less resource hungry than linux 2.4 kernels (???)
Advantages of the Linux kernel for desktop computers:
Better video support (hardware accelerated graphics, framebuffer device --> important for embedded systems)
Better audio support with ALSA
ReiserFS, Macintosh file system support, NTFS read support
Firewire support, Power Management support, PCMCIA support
I am right that *BSD kernels don't support the above?
Apple is building its MacOS X on a similar foundation as Linux (i.e. BSD), so that disproves your claim. We already have advanced multimedia support (think of ALSA and MESA...) and journaling file systems (ReiserFS) in Linux. Please remember that Linux is a kernel. Nobody would stop you to build a distribution that takes away all Unix-inherited complexity. Some ideas:
Throw multiuser and files access permissions out of the system. have the user automatically login and work as 'root' just as in windows 95/98/me and in macos. sure, this creates a lot of security issues, but they could be tolerated on desktop machines with dialup-only internet access. by far more simple for unsophisticated users.
Simplify the file system structure. If multiuser functionality has been removed, it is only longer necessary to have/home,/sbin,/usr/sbin and to have both global and user-specific configuration files. Join/bin,/sbin,/usr/bin,/usr/sbin, for example. Rename all system directories so that they are easily understandable in natural language:/usr/bin to/Programs,/etc to/Programs/Settings/lib to/Programs/Data. Create/Fonts,/Sounds,/Pictures,/Documents, and so on.
Throw out X11 - since no desktop user needs its network functionality - and replace it with a framebuffer-based GUI.
Create lightweight desktop applications not with configurability, but simplicity in mind. Avoid redundant functionality (i.e. button bars doubling menu entries). Most of these apps are already there, just port them to a common toolkit (fltk, for example).
Reduce inter-application interfaces to classic Unix pipes, sockets and libraries. Avoid bloat and slowdown through Corba and similar interfaces.
Adapt and simplify LinuxConf to act as the system configurator
Standardize on one scripting language in your "distribution" (for example, Python). Avoid that several bloated scripting languages have to reside on the system just because system utilies (package managers etc.) need them.
I agree that the resulting system will have litte in common of what we know and appreciate in GNU/Linux. But it would be the perfect system for people who don't want to replace the complexity and impenetrability of Windows with yet another type of complexity and impenetrability. Hammering nice graphical interfaces on top of that complexity won't help.
Miguel de Icaza says that SO 6.0 is based on Gnome's Bonobo component model. AFAIK, Bonobo is neither released yet, nor are there any Gnome applications making use of pre-release Bonobo versions. So I guess the GPL'ed StarOffice will not build (yet) and take a long time before it's ready for use, probably as long as Mozilla.
The operating system clause in the GPL allows to link GPL code against proprietary libraries if they are part of an operating system. Still it doesn't allow to link GPL code against libraries which are Free Software but whose licensing is incompatible to the GPL. So I can write GPLed software which uses the Motif toolkit (because Motif is part of some commercial Unices). but I can't write GPLed code which links to the Qt 2.0 library whose license you endorsed as Free Software. This strikes me as an inconsistency in copyleft. What do you think of
Abandoning the GPL operating system clause altogether. Since free OSs have become complete, it is no longer necessary to link Free Software against non-free software.
Modifying the GPL operating system clause so that it no longer allows to link GPL code against proprietary libraries, but to any kind of libraries which are Free Software according to the Debian Free Software Guidelines.
Does it really matter anymore if newer Linux distros no longer run well on old 386's?
For me, it does. I have a 386sx laptop with 2 MB RAM and a 40 MB HD and have been desperately looking for a free (as in speech) OS for it. FreeDOS turned out to be too slow, Linux too big, and V2OS isn't there yet. And Minix gives me small versions of all the Unix tools I need. This made my day.
The question here is not whether framebuffer-based GUI Toolkits render X11 obsolete. There are many reasons why X11 will remain the better graphics subsystem for workstations:
X11 has network transparency
X11 runs in the userspace, so misconfiguration (or just switching your video card or screen) doesn't lock up the system
XFree 4.0 has many highend features which framebuffer-based GUIs will lack: multihead support, truetype support, modular drivers, 3D/OpenGL etc.etc.
X11 is GUI toolkit agnostic. You can run KDE, Gnome, GNUstep, Tk, Motif... apps under one X11 desktop, which you can't on a framebuffer-based desktop
That said, I find Qt/embedded an excellent idea, moreover in the light of the recent progress in the efforts to port Linux to Psion PDAs and WinCE palmtops. For such devices, X11 is bloated. It will be nice to have Qt/KDE applications such as KLyX available on PDAs in the not-so-distant future. I hope the GTK/Gnome folks take up the idea and do the same with GTK/GDK, hopefully in a way that makes it possible to run both Qt- and GTK-based software under the same framebuffer-based GUI.
These developments are important in a time where companies like Samsung are working on Linux-based PDAs with proprietary user interfaces and proprietary applications on top of the kernel. Although it's good that Linux becomes popular for settop boxes, PDA and other embedded devices, it would be a substantial drawback for the cause of Free Software if proprietary GUIs and userspaces would prevail on such systems. So Trolltech's move deserves applause from our community.
Since FreeDOS includes the full source code, can it be easily compiled on machines with different CPUs than x86 (such as Alpha, PowerPC, Sparc, StrongARM...)? I know this idea may sound weird, because it would also require to recompile DOS apps.
On the other hand, FreeDOS might be an efficient OS on embedded systems and palmtops, perhaps more efficient than Linux and ELKS (the 16-bit Linux kernel subset) if hardware capabilities are seriously limited.
LyX has a clean, consistent interface and makes writing cleanly-marked up, structured documents a snap even for computer novices. It combines the power of a superior word processing engine (LaTeX) with the ease-of-use of a program like WriteNow (Mac/NeXT), AbiWord (Linux/GTK) or WordPad (Windows). LyX demonstrates that a good interface is not just about simplifying work for beginners, but about making everone more productive, since it vastly speeds up LaTeX-editing (at least for me). At the same time, LyX is highly customizable and can be fully controlled via Keyboard shortcuts. LyX IMHO is a shining example of how Linux GUI software should always be: Keep all the power of Unix and make it easy to use.
P.S.: I know that LyX is still based on the old, non-free XForms-Toolkit, however the LyX team is working on making the program GUI-independent, so that GTK-, KDE- and XForms-Frontends will be possible.
Slashdot Mirror
You could depart from this link page; particular recommendations: jodi.org, easylife.org, irational.org.
The only real advantage of the PPC at the moment is that it lacks a lot of backwards compatibility cruft and, because of its RISC design, consumes less power and spreads less heat. It is a fine notebook CPU (and Apple is a fine notebook manufacturer). But Apple seems to have had no other chance but giving up this advantage by selling its newest line of desktop G4 Macs with dual CPUs, keeping up with Intel at least halfway with such a "hack".
While Debian's Free Software-only politics was controversial some years ago - anyone remember the ugly term "Debian Nazi"? -, it no longer seems so due to DMCA, patenting, and perversions of copyright. Debian has done invaluable work for the Free Software community by thoroughly reviewing the licensing of the software it ships, freeing users from the hassle to become legal experts. Debian users enjoy both the technical excellence and the legal safety of running Debian "main".
It would be good if the FSF Award were given to Debian to finance work on the new Debian installer. This is the last showstopper piece which prevents massive newbie user adoption of this distribution.
But really, what a waste of electricity, heat, and what a noise pollution. I'm waiting for desktop CPUs with SpeedStep which clock down to 100 MHz when you're doing vi editing and go up to 2.8 GHz, turning on all fans, when you compile software or transcode video streams.
I hope there will be enough consumer demand for such CPUs, pushing AMD/Intel towards saner technology.
If Free Software/Open Source doesn't want to be (wrongly) put in the same bag as the dotcom bubble rhetoric of 1996-1999, it should dissociate itself from the rhetoric bubbles of ESR.
Perl allows coding styles so different that two Perl programs may look as if they were written in entirely different languages. Perl6 seems to further this balkanization. This is why I consider Perl the wrong tool for large projects involving many programmers. (Imagine a Mozilla, Emacs or KDE written in Perl - shudder...)
The bottom line is that Perl is simply not the right tool for general programming purposes. I only use Perl as what it was originally intended to be - a "practical extraction and report generation language" that excels at scanning and computing huge amounts of text, as an integrated, improved replacement of the classical shell/sed/awk/grep etc. toolchain. Perl code can be readable and maintainable if it's written in C style and deliberately excludes the more esoteric features of the language. For anything else, and any "serious" - i.e. complex - programming, pick C/C++ or Python. It is no contradiction for me to concede this and still be a Perl afficionado.
This not only creates issues of look'n'feel consistency and interoperability (to mention only drag'n'drop...), but since all these libraries duplicate functionality of their counterparts,
they result in a bloated "Linux Desktop". One might argue that RAM is cheap, but increased load times really suck. While I used to have reservations towards KDE because of its initial licensing issues and seeming bloat, it is seems more and more as if it is the only professional, well-crafted free X11 desktop environment & component architecture (aside from GNUstep which doesn't get off the ground), so I hope that KDE becomes the unified standard API for desktop applications & overcomes the fragmentation and inefficiency on the GNU/Linux desktop.
- better responsiveness under heavy load - Linux 2.4.x with its VM problems is particularly bad in comparison
- smaller base software/dependencies; BSD libc is much smaller than glibc;
/bin/sh points to ash, so all shell and system scripts are ash processes (and not bloated bash processes); classic Unix tools are less heavyweight than GNU tools (Remember: you can use GNU tools, bash etc., but they're not a dependency) - mature device file system
- Clear separation of what belongs to the core OS & third party software (=ports system)
- Best package management for installing/compiling from source (Debian's apt-get src isn't there yet)
- Kernel features are fewer, but proven & tested (as opposed to many experimental or not-yet-mature drivers/subsystems/filesystems in Linux)
- standard file system is 64 bit, allowing big single files
- Package selections show that FreeBSD maintainers are real Unix afficionados (vim 6.0 available etc.)
- the whole system is/feels very solid and mature
What I dislike:- distribution/ports mixes free and non-free software (Motif etc.) without prompting the user what is free and not; bad not only for Free Software zealots, but also for people who want to make sure they can use software without limitations in their environment (FreeBSD looks as it is made by people for whom software freedom is a secondary concern)
- available for a smaller no. of hardware architectures than Linux (or use NetBSD on non-x86 platforms, but that's already a different OS)
- no journalling filesystems (no ReiserFS, no XFS), a very small number of filesystems supported
- no
/proc, no framebuffer device, no ALSA sound drivers, no hardware accelerated graphics in the kernel - much worse SMP support than current Linux kernels
. GNU/Linux feels more "modern" than FreeBSD, while FreeBSD is comparatively "conservative", but also more solid. Draw your own conclusions.Here are some ideas:
- Improve overall responsiveness, i.e. decrease load times, memory usage, etc. I understand that a lot of work is being done in this direction - which is very good (as opposed to Gnome, SCNR) -, but KDE still isn't there.
- Configuration/setting menus are still confusing for newbies and experienced users alike because they're spread over many menus (especially in konqueror) and sometimes seem to be part of the application, sometimes part of the configuration center.
- Interface redundancies (i.e. multiple menu methods for the same functions) are also confusing, or it should at least be possible to turn them off. (It would be great if right-click context menus could be turned off, for example.)
- Allow to configure KDE as a web browser-centric desktop without the classical floating windows + launchbar paradigm. It is already possible to start X11 with konqueror as the window manager (put exec konqueror into
.xinitrc), run it full-screen and access applications only as konqueror-embedded parts. (Like the konqueror-embedded terminal, for example.) Hardly anyone has realized how f***ing great this is! I know many computer-newbie user who can handle the Web, but can't handle classical WIMP GUIs, and prefer web-based applications simply because they find them easier to use. With konqueror as a framework for browser-based/-embedded applications, GNU/Linux could make real inroads into desktop computing! (You sell people a computer that "as simple to use as a web browser".)
- For people like me: Allow to toggle icon buttons with text buttons
- And, finally: Create a framework that maps the shell/console onto the desktop. Imagine GUI wrappers for all classical Unix console applications (grep, cat, sed, find...) which allow to toggle options by GUI menus AND build pipes GUI-style, i.e. by dragging pipes between icon representations of command-line tools with the mouse. Steal from visual programming environments (like MAX or, available for GNU/Linux, PD) to achieve this.
FlorianRemember that Alan Kay/Xerox PARC invented the GUI to make average users capable of programming, and that Apple & Microsoft left out half of the concept when they brought it to mainstream computing. Free Software should do better here.
I own both the Tandy (in its European Olivetti-branded variant) and the Amstrad. The big plus of the Tandy are the display and the keyboard. Technically, the Amstrad is better - especially with a PCMCIA SRAM card -, and its much lower weight is also a big plus. I recently bought a foldable keyboard for my Palm, but found it a much less reliable and practical solution than the Armstrad.
Florian
Examples:
- The standard LSB shell is bash,
- the standard LSB tar is GNU tar (with the -z option and others).
Making them a standard requirement rules out more lightweight implementations, such as the ash shell and the busybox or the BSD tools. This in turn makes it impossible to build embedded Linux systems conforming to the LSB - be it PDA Linux or be it one-disk routers.Instead of targetting only server/workstation setups, I would have preferred the LSB to settle on low common denominators, like
This would still allow anyone to make bash the standard shell and GNU tar the standard tar in an LSB-compliant distribution, but it would require third-party software makers to take care that their shell scripts run on ash as well as on bash if they want the LSB compliance sticker for their product.
(P.S.: That said, I would love to see GNU/Linux distributions - above all: Debian - to scale down to a basic ash/busybox setup, which would require [a] to get rid of bash/GNU tool specific syntax in the setup and configuration scripts, [b] free all their package managing from dependencies on scripting languages like Perl, using ash scripts + minimal sed + minimal awk for simple tasks and compiled C code for more complicated stuff.)
IMHO, antiword is by far the best Word-to-Ascii converter out there. It even renders footnotes, can be used in pipes and is much faster than wvWare. The program is GPL and comes for a variety of OS platforms. As the moderator of a mailing list, I regularly use it to convert *.doc attachments. (One should patch majordomo so that it automatically filters *.doc attachments through antiword. It has worked flawlessly for me since more than a year. It surprises me quite a lot that such a superb program is so litte known in the Free Software community.
What if web masters manipulate the spider and return false search results (for luring people into pr0n, spam, propaganda...)?
The grub concepts sounds good, but I doubt it will stand reality unless you create a complex "web of trust" system. (Which in turn would be too complex for grub to become popular.)
Some advantages of *BSD kernels I can think of
- Better reponse under high network load
- Less resource hungry than linux 2.4 kernels (???)
Advantages of the Linux kernel for desktop computers:- Better video support (hardware accelerated graphics, framebuffer device --> important for embedded systems)
- Better audio support with ALSA
- ReiserFS, Macintosh file system support, NTFS read support
- Firewire support, Power Management support, PCMCIA support
I am right that *BSD kernels don't support the above?- Throw multiuser and files access permissions out of the system. have the user automatically login and work as 'root' just as in windows 95/98/me and in macos. sure, this creates a lot of security issues, but they could be tolerated on desktop machines with dialup-only internet access. by far more simple for unsophisticated users.
- Simplify the file system structure. If multiuser functionality has been removed, it is only longer necessary to have
/home, /sbin, /usr/sbin and to have both global and user-specific configuration files. Join /bin, /sbin, /usr/bin, /usr/sbin, for example. Rename all system directories so that they are easily understandable in natural language: /usr/bin to /Programs, /etc to /Programs/Settings /lib to /Programs/Data. Create /Fonts, /Sounds, /Pictures, /Documents, and so on.
- Throw out X11 - since no desktop user needs its network functionality - and replace it with a framebuffer-based GUI.
- Create lightweight desktop applications not with configurability, but simplicity in mind. Avoid redundant functionality (i.e. button bars doubling menu entries). Most of these apps are already there, just port them to a common toolkit (fltk, for example).
- Reduce inter-application interfaces to classic Unix pipes, sockets and libraries. Avoid bloat and slowdown through Corba and similar interfaces.
- Adapt and simplify LinuxConf to act as the system configurator
- Standardize on one scripting language in your "distribution" (for example, Python). Avoid that several bloated scripting languages have to reside on the system just because system utilies (package managers etc.) need them.
I agree that the resulting system will have litte in common of what we know and appreciate in GNU/Linux. But it would be the perfect system for people who don't want to replace the complexity and impenetrability of Windows with yet another type of complexity and impenetrability. Hammering nice graphical interfaces on top of that complexity won't help.Here is another mirror of the screenshots. It's located on a German university server and should work better for Europeans.
Miguel de Icaza says that SO 6.0 is based on Gnome's Bonobo component model. AFAIK, Bonobo is neither released yet, nor are there any Gnome applications making use of pre-release Bonobo versions. So I guess the GPL'ed StarOffice will not build (yet) and take a long time before it's ready for use, probably as long as Mozilla.
- Abandoning the GPL operating system clause altogether. Since free OSs have become complete, it is no longer necessary to link Free Software against non-free software.
- Modifying the GPL operating system clause so that it no longer allows to link GPL code against proprietary libraries, but to any kind of libraries which are Free Software according to the Debian Free Software Guidelines.
?Florian
Does it really matter anymore if newer Linux distros no longer run well on old 386's?
For me, it does. I have a 386sx laptop with 2 MB RAM and a 40 MB HD and have been desperately looking for a free (as in speech) OS for it. FreeDOS turned out to be too slow, Linux too big, and V2OS isn't there yet. And Minix gives me small versions of all the Unix tools I need. This made my day.
- X11 has network transparency
- X11 runs in the userspace, so misconfiguration (or just switching your video card or screen) doesn't lock up the system
- XFree 4.0 has many highend features which framebuffer-based GUIs will lack: multihead support, truetype support, modular drivers, 3D/OpenGL etc.etc.
- X11 is GUI toolkit agnostic. You can run KDE, Gnome, GNUstep, Tk, Motif... apps under one X11 desktop, which you can't on a framebuffer-based desktop
That said, I find Qt/embedded an excellent idea, moreover in the light of the recent progress in the efforts to port Linux to Psion PDAs and WinCE palmtops. For such devices, X11 is bloated. It will be nice to have Qt/KDE applications such as KLyX available on PDAs in the not-so-distant future. I hope the GTK/Gnome folks take up the idea and do the same with GTK/GDK, hopefully in a way that makes it possible to run both Qt- and GTK-based software under the same framebuffer-based GUI.These developments are important in a time where companies like Samsung are working on Linux-based PDAs with proprietary user interfaces and proprietary applications on top of the kernel. Although it's good that Linux becomes popular for settop boxes, PDA and other embedded devices, it would be a substantial drawback for the cause of Free Software if proprietary GUIs and userspaces would prevail on such systems. So Trolltech's move deserves applause from our community.
On the other hand, FreeDOS might be an efficient OS on embedded systems and palmtops, perhaps more efficient than Linux and ELKS (the 16-bit Linux kernel subset) if hardware capabilities are seriously limited.
P.S.: I know that LyX is still based on the old, non-free XForms-Toolkit, however the LyX team is working on making the program GUI-independent, so that GTK-, KDE- and XForms-Frontends will be possible.