Author: JT Smith
Author: JT Smith
Workstation 7.0 includes e-mail, Mozilla, and PDA hot-sync capabilities. Its graphical user interface installer allows the user to complete
installation by entering a single password. Workstation 7.0 also allows for optional installation of Windows95/98 in free disk space or optional
dual-boot installation with Windows95/98. In addition, Workstation 7.0 provides ADSL interface for high-speed network connection and
extended support for various digital media including MP3and digital video data.
System Requirements
CPU: Intel or Intel Compatible Pentium level and above
Memory: 64MB and above, 128MB and above recommended
HD: 2GB and above recommended
CD-ROM: ATAPI/SCSI
Floppy: 1.44MB
About Turbolinux, Inc.
Founded in 1992, Turbolinux develops Linux-based software solutions for Internet and enterprise computing infrastructure, including reliable,
available and scalable operating systems for workstations and servers and software clustering solutions for computing traffic management and
peer-to-peer distributed computing. Backed by more than $95 million in investments from some of the world’s leading technology companies,
including Compaq, Dell, Fujitsu, Hitachi, IBM, Intel, NEC, Novell, Oracle, SGI and Toshiba, Turbolinux is headquartered near San Francisco with
offices around the world. For more information, visit the Turbolinux Web site at http://www.turbolinux.com.
Author: JT Smith
Category:
Author: JT Smith
ChangeLog 1.4.1 to 2.0
- The Version number is now 2.0.
- KDevelop's user interface has been rewritten with the usage of the multiple document
interface architecture, allowing to view several windows. Also several views for the same
file can be used.
- The view mode can be switched between Childframe mode, Toplevel mode and TabPage mode
- The bookmark handling and the internal debugger were adapted to the new GUI.
===> Both features are possible because now we base on QextMDI, a library which supports
advanced MDI for Qt and KDE.
- A new configuration wizard (based on QWizard) replaces the old, messagebox based one.
- Project sessions (.kdevses) were introduced.
- Dockwidget usage has been extended to dock/undock the tabulator windows in the
Treeview and Outputview.
- New templates for implementing a KDE/Qt style library and KControl modules have been
added as well as templates for Konqueror plugins and Kicker apps.
- The kde-common/admin copy (admin.tar.gz) has been updated to the latest version in
KDE CVS. Users of versions prior to 2.0 are advised to update their project's admin
directory with that to support newer versions of autoconf and automake.
- KDevelop now uses the new tip of day dialog from kdelibs.
- The user manual has been extended to match the new GUI layout plus adds a chapter for
using Qt Designer with KDevelop projects.
- A newly added ctags-based search database enables "Goto definition/declaration" and
the switch between .h and .cpp file. It requires ctags-5.0.1.
- The compiler output is shown coloured.
- Man pages are accessable via KDevelop's help browser.
- The functionality of KDevelop was splitted in shared libraries.
- Sounds for KDevelop events (system notification in KDE's Control Center) are supported.
- The configuration of shared libs subprojects was improved.
- Lots of small and big bugfixes are made, especially in the editor.
- The internal debugger of KDevelop can now recognize Qt-3.0 strings.
- .po and .xpm files can be opened as ASCII files.
Note: KDevelop-2.0 bases on the source code of the previously released version 1.4.1.
Author: JT Smith
Also, I’ve been getting a _lot_ of patches, and if yours didn’t show up
it’s because I got too many. Never fear, there’s always tomorrow. Except
in this case it’s “in a week or two”.
Changelog appended.
Linus
-----
final:
- David Miller: sparc updates, FAT fs fixes, btaudio build fix
- David Gibson: Orinoco driver update
- Kevin Fleming: more disks the HPT controller doesn't like
- David Miller: "min()/max()" cleanups. Understands signs and sizes.
- Jens Axboe: CD updates
- Trond Myklebust: save away NFS credentials in inode, so that mmap can
writeout.
- Mark Hemment: HIGHMEM ops cleanups
- Jes Sorensen: use "unsigned long" for flags in various drivers
pre4:
- Tim Hockin: NatSemi ethernet update
- Kurt Garloff: make PS/2 mouse reconnect adjustable like 2.2.x
- Daniel Phillips: unlazy use-once
- David Miller: undo poll() limit braindamage
- me: make return value from do_try_to_free_pages() meaningful
pre3:
- Patrick Mochel: fix PCI:PCI bridge 64-bit memory type detection
- me: more forgotten nfsd off_t -> loff_t
- Alan Cox: ide driver merge
- Eric Lammerts, Rik van Riel: when oom, kill all threads.
- Ben LaHaise: use down_read, not down_write() in map_user_kiobuf.
We don't change the mappings, we just read them.
- Kai Germaschewski: ISDN updates
- Roland Fehrenbacher: sparse lun check
- Tim Waugh: handle awkward Titan parallel/serial port cards
- Stephen Rothwell: APM updates
- Anton Altaparmakov: NTFS updates
pre2:
- me: fix forgotten nfsd usage of filldir off_t -> loff_t change
- Alan Cox: more driver merges
pre1:
- Rui Sousa: emu10k1 module fixes, remove joystick part.
- Alan Cox: driver merges
- Andrea Arkangeli: alpha updates
- David Woodhouse: up_and_exit -> complete_and_exit
- David Miller: sparc and network update
- Andrew Morton: update 3c59x driver
- Neil Brown: NFS export VFAT, knfsd cleanups, raid fixes
- Ben Collins: ieee1394 updates
- Paul Mackerras: PPC update
- me: make sure we don't lose position bits in "filldir()"
Category:
Author: JT Smith
Release 2.2.4 of the GNU C library is now available at
ftp://sources.redhat.com/pub/glibc/releases
and (hopefully soon)
ftp://ftp.gnu.org/pub/gnu/glibc
and all the mirror sites around the globe.
The new files are
glibc-2.2.4.tar.bz/2 (also .gz)
glibc-linuxthreads-2.2.4.tar.bz/2 (also .gz)
glibc-2.2.3-2.2.4.diff.bz/2 (also .gz)
and for those following the test releases
glibc-2.2.4pre3-2.2.4.diff.bz/2 (also .gz)
The patch from 2.2.3 is pretty big but a lot are non-code-related
changes. The code which did changed mainly got better due to bugs
fixed. There are only a few new features:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Version 2.2.4
* Stephen Moshier implemented cosh, expm1, log1p, acos, sinh, tanh,
asinh, atanh, j0 for the 128-bit long double format.
* Bruno Haible updated all the code handling Unicode in some form to
support Unicode 3.1.
* Speed of regex for single-byte locales is back to previous levels.
Patch by Isamu Hasegawa.
* Alpha, SPARC, and IA-64 now also using floating stacks.
* Startup time of internationalized applications greatly improved through
iconv cache. Use iconvconfig to generate the cache file.
Contributed by Ulrich Drepper.
* The IA-64 specific part of ld.so was rewritten to eliminate some pretty
severe performance problems. Patch by David Mosberger.
* The Hurd port got a lot more functionality like AIO, various stdio
extensions, etc. Mainly done by Roland McGrath.
* mtrace can now lookup symbols in shared libraries.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This release of the library runs on the following targets:
*-*-gnu GNU Hurd
i[3456]86-*-linux-gnu Linux-2.x on Intel
m68k-*-linux-gnu Linux-2.x on Motorola 680x0
alpha-*-linux-gnu Linux-2.x on DEC Alpha
powerpc-*-linux-gnu Linux-2.x on PowerPC systems
sparc-*-linux-gnu Linux-2.x on SPARC
sparc64-*-linux-gnu Linux-2.x on UltraSPARC
s390-*-linux-gnu Linux-2.x on S390
sh*-*-linux-gnu Linux-2.x on SH
ia64-*-linux-gnu Linux-2.x on IA-64
Work is in progress to make the following targets work (again):
arm-*-linux-gnu Linux-2.x on ARM
hppa*-*-linux-gnu Linux-2.x on HP/PA
mips*-*-linux-gnu Linux-2.x on MIPS
Previous releases worked on the following targets, the current status
is unknown:
arm-*-none ARM standalone systems
arm-*-linuxaout Linux-2.x on ARM using a.out (obsolete?!)
We believe that this release is very stable, more so than any before.
Upgrading is highly encouraged.
BUT: updating the C library is no trivial task and it is very easy
to damage one's system. Therefore, persons who do not exactly know
what to do, should consider using a binary distribution instead, when
it becomes available. All major Linux distributors will hopefully
base their next release on glibc 2.2.4. Don't tell us you haven't
been warned. Another reason why not everybody should think about
compiling glibc is the disk and CPU requirements: on Intel platforms
the full build requires about 330MB plus the space you need to install
it. This number is higher on most RISC platforms. During the
compilation the compiler will need large amounts of virtual memory.
We are talking about 100MB on Intel and 200MB on Alpha. If using the
`-j' option of make these numbers grow linearly. Building the
complete library without profiling support on a 2xPIII@550MHz system
takes about 32 minutes, checking adds another 18 minutes. On not
highly tuned and slower systems the times are very much higher and it
possibly takes several days on very old and slow systems. The '-j'
option for make is very useful on SMP systems, the Makefiles are save
for builds with high '-j' numbers (except when the compilation happens
in the source directory; simply create a new directory and compile in
that one instead).
It is generally always a good idea to build in a separate directory
and simply configure using
/path/to/glibc-2.2.4/configure ...options for configure...
In case you decide to compile glibc yourself you need to read the
files INSTALL and FAQ. It will explain among other things which tools
are necessary. The most important one is the compiler. Although
other versions might work it is recommended to get at least gcc 2.95.3
plus some patches as explained in
http://sources.redhat.com/ml/libc-alpha/2001-08/msg00114.html
Maybe the patches are meanwhile in the gcc CVS archive and using it is
all that is needed. Earlier gcc versions are known to produce
incorrect code in certain situations. Even better optimized code can
be generated with later development versions of the compiler.
And while we are talking about compilers: gcc 3 can NOT be used.
In case a compilation fails and the compiler is not 2.95.3 (+ patch)
get this compiler version first before reporting problems. If you run
make with the -n option and search for errors in the log make sure you
distinguish between real bugs and cases where the glibc Makefiles
explicitly ignore failures.
You may need development versions of the compilation tools on recently
supported architectures. The requirements for MIPS are described in
the FAQ. For others contact the developers working on tools for the
specific architecture.
In case you are modifying the source files which will cause autoconf
to run make sure you have autoconf 2.13 installed and NOT version
2.50 and up. These versions will not work.
One Linux systems the configure script has a new option
`--enable-kernel' (find the documentation in the INSTALL file). This
option allows one to strip out compatibility code for older kernel
versions. This is of interest since configuring for a 2.4.x kernel
reduces the libc size by about 1%. This is no high percentage but all
the code gone is in the by far most often used functions. The
compatibility code is needed because of poor design decisions of the
kernel developers who constantly have to adjust the interface to new
requirements. If you never expect to run kernel versions older than
the one used at compile time of the library it is a good idea to pass
`--enable-kernel=current' to configure. But be careful since with an
older kernel the program won't even start and the whole system might
be rendered useless (unless backup kernels are available).
The 2.2.x release should be binary compatible with the 2.1 and earlier
releases. All correct programs should continue to run. This does
not mean that programs compiled on a system running glibc 2.2.x will
run on systems with only glibc 2.1. Compatibility is always in one
direction. Systems with glibc 2.1 will not even attempt to run
binaries generated with glibc 2.2.x so there is not much to worry about.
The internal locale format has been changed (again, new in 2.2.4).
All locale information has to be regenerated with localedef. Simply run
make localedata/install-locales
to install all the files. This might take a while and using the -j
option on SMP systems. If you are upgrading a live system with glibc
2.1 or before you will end up with two sets of the locale data in two
different places (the old data in /usr/share/locale, the new code in
/usr/lib/locale). Keep the old data around until all statically
linked applications which use locales are recompiled. Then remove the
files LC_CTYPE, LC_COLLATE, LC_NUMERIC, LC_MONETARY, LC_TIME, and
SYS_LC_MESSAGES in all subdirectories below /usr/share/locale.
There are normally no problems to be expected when compiling code with
the new glibc version. In a few cases programs make wrong assumptions
and the build will suddenly fail (recent example: using CLK_TCK in
initializers for static or global variables which is wrong since is
CLK_TCK is not guaranteed to be a constant). Make sure you review
the appropriate standards before you claim to have found a bug.
Problems should all be reported using the `glibcbug' shell script.
NEVER send mail to me and preferably any other developer directly;
I won't even read it. Mailing lists not only there to distribute the
workload, they also help to archive questions and answers. Simply run
this script, fill out the information and you are set. If at the time
you start the script it complains like this
/usr/bin/glibcbug: emacs: command not found
set one of the environment variables EDITOR and VISUAL (this should
happen on every system automatically):
env EDITOR=vi glibcbug
Do this also if you don't want to edit the bug report in Emacs (I
cannot imagine why not but...)
Before sending a bug report make sure you have read the BUGS and the
FAQ files which come with the glibc sources. You won't even get an
answer if it is obvious you haven't read these files. It is also
helpful to scan the appropriate newsgroups and mailing lists to see
whether somebody else already had this problem. There is another
thing we don't want to hear about: the size. glibc is big, but this
is necessary for a multi-platform Unix library.
In case the bug database is once again offline send the reports to the
libc-alpha@sources.redhat.com mailing list.
Responsible for this release are the usual suspects whom I want to
thank:
Bruno Haible
Isamu Hasegawa
Andreas Jaeger
Jakub Jelinek
Geoff Keating
Mark Kettenis
Kaz Kylheku
H.J. Lu
Roland McGrath
Andreas Schwab
And now for some not so nice things.
Stallman recently tried what I would call a hostile takeover of the
glibc development. He tried to conspire behind my back and persuade
the other main developers to take control so that in the end he is in
control and can dictate whatever pleases him. This attempt failed but
he kept on pressuring people everywhere and it got really ugly. In
the end I agreed to the creation of a so-called "steering committee"
(SC). The SC is different from the SC in projects like gcc in that it
does not make decisions. On this front nothing changed. The only
difference is that Stallman now has no right to complain anymore since
the SC he wanted acknowledged the status quo. I hope he will now shut
up forever.
The morale of this is that people will hopefully realize what a
control freak and raging manic Stallman is. Don't trust him. As soon
as something isn't in line with his view he'll stab you in the back.
NEVER voluntarily put a project you work on under the GNU umbrella
since this means in Stallman's opinion that he has the right to make
decisions for the project.
The glibc situation is even more frightening if one realizes the story
behind it. When I started porting glibc 1.09 to Linux (which
eventually became glibc 2.0) Stallman threatened me and tried to force
me to contribute rather to the work on the Hurd. Work on Linux would
be counter-productive to the Free Software course. Then came, what
would be called embrace-and-extend if performed by the Evil of the
North-West, and his claim for everything which lead to Linux's
success.
Which brings us to the second point. One change the SC forced to
happen against my will was to use LGPL 2.1 instead of LGPL 2. The
argument was that the poor lawyers cannot see that LGPL 2 is
sufficient. Guess who were the driving forces behind this.
The most remarkable thing is that Stallman was all for this despite
the clear motivation of commercialization. The reason: he finally got
the provocative changes he made to the license through. In case you
forgot or haven't heard, here's an excerpt:
[...] For example, permission to use the GNU C Library in non-free
programs enables many more people to use the whole GNU operating
system, as well as its variant, the GNU/Linux operating system.
This $&%$& demands everything to be labeled in a way which credits him
and he does not stop before making completely wrong statements like
"its variant". I find this completely unacceptable and can assure
everybody that I consider none of the code I contributed to glibc
(which is quite a lot) to be as part of the GNU project and so a major
part of what Stallman claims credit for is simply going away.
This part has a morale, too, and it is almost the same: don't trust
this person. Read the licenses carefully and rip out parts which give
Stallman any possibility to influence your future. Phrases like
[...] GNU Lesser General Public License as published by the Free
Software Foundation; either version 2.1 of the License, or (at your
option) any later version.
just invites him to screw you when it pleases him. Rip out the "any
later version" part and make your own decisions when to use a
different license since otherwise he can potentially do you or your
work harm.
In case you are interested why the SC could make this decision I'll
give a bit more background. When this SC idea came up I wanted to
fork glibc (out of Stallman's control) or resign from any work. The
former was not welcome this it was feared to cause fragmentation. I
didn't agree but if nobody would use a fork it's of no use. There
also wasn't much interest in me resigning so we ended up with the SC
arrangement where the SC does nothing except the things I am not doing
myself at all: handling political issues. All technical discussions
happens as before on the mailing list of the core developers and I
reserve the right of the final decision.
The LGPL 2.1 issue was declared political and therefore in scope of
the SC. I didn't feel this was reason enough to leave the project for
good so I tolerated the changes. Especially since I didn't realize
the mistake with the wording of the copyright statements which allow
applying later license versions before.
I cannot see this repeating, though. Despite what Stallman believes,
maintaining a GNU project is NOT a privilege. It's a burden, and
the bigger the project the bigger the burden. I have no interest to
allow somebody else to tell me what to do and not to do if this is
part of my free time. There are plenty of others interesting things to
do and I'll immediately walk away from glibc if I see a situation like
this coming up again. I will always be able to fix my own system (and
if the company I work for wants it, their systems).
--
---------------. ,-. 1325 Chesapeake Terrace
Ulrich Drepper ,-------------------' Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `------------------------
Category:
Author: JT Smith
Category:
Author: JT Smith
Category:
Author: JT Smith
Category:
Author: JT Smith