Re: Should I switch? [was Re: A novel idea....]
7. FreeBSD is developed very rapidly. Especially if you subscribe to mailing lists, you can see bugs fixed almost as soon as they are mentioned. New features are added more conservatively, however. New stuff is tried out in -CURRENT, where the heavy-duty FreeBSD hackers make it stable, then merge it into -STABLE. The reason Linux became more popular than FreeBSD is, as I've read: Linux development is helter-skelter--anybody can make changes to the system and redistribute them with ease. As a consequence, a wide range of people worked to develop the components on your Debian system. This distribution and encouragement led to confusion, but also popularity. FreeBSD, on the other hand, is maintained by a fixed group of committers. While you can still modify your system, it is more difficult to get random changes into the main code tree. The result is a more structured and sane development process, with an emphasis on stability rather than untested additions. While it's true anyone can make changes to Linux and redistribute them with ease, I don't see how it's a point of difference. What prevents me from taking a bit of BSD, changing it and distributing it how I will? Actually getting a change into a distribution of Linux requires convincing a Responsible Person that it's a good idea, and that Responsible Person is going to take care either because his job may be on the line if he gets it wrong, or it's his pet part of the overall Scheme of Things and he really truly cares about it. In that regard, I don't see that FreeBSD is a lot different from a distribution. Remember too that a good deal of the software on BSD is the same as is on linux. -- Cheers John Summerfield http://www2.ami.com.au/ for OS/2 linux information. Configuration, networking, combined IBM ftpsites index. Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Note: mail delivered to me is deemed to be intended for me, for my disposition. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Broken PCI-IDE RZ1000 ata
Dear All, Well, that chip is so broken by design, no software workaround can help its misery, a hardware fix exists, but cant (easily) be As Volker notes; Linux can work round it. So can OS/2. I don't know the details, but there ARE modes where it works. Nope, there are not, even the manufacturer agrees to that As much as I like ... err ... technical discussion, perhaps it's time that either side came up with something solid. "Linux can" and "Manufacturer agrees" are not solid, IMHO. The Linux code states that the workaround is perfect in what source file? I did not say it's perfect. However, read this: /usr/src//linux-2.2/drivers/block/rz1000.c It starts: /* * linux/drivers/block/rz1000.c Version 0.05 December 8, 1997 * * Copyright (C) 1995-1998 Linus Torvalds author (see below) */ /* * Principal Author: [EMAIL PROTECTED] (Mark Lord) * * See linux/MAINTAINERS for address of current maintainer. * * This file provides support for disabling the buggy read-ahead * mode of the RZ1000 IDE chipset, commonly used on Intel motherboards. * * Dunno if this fixes both ports, or only the primary port (?). */ The comments in OS/2 fixpacks tell how to use it on OS/2. Use the search program in the web pages at http://os2.ami.com.au/os2/ to locate directories with names beginning wr_0 (Warp 3) or wr_m0 (Warp 4), read the readmes. All it will establish is that they work; not what code trickery is needed. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Broken PCI-IDE RZ1000 ata
It seems Volker Stolz wrote: The RZ1000 PCI-IDE controller found on at least one Intel board is severely broken and requires a workaround which is available for Linux (at least it turned up in the config for 2.4.0, though the board should be a couple of years old, it's for regular Pentium-I). Could anyone comment on this to get it working with FreeBSD? sysinstalls gets write-errors after a couple of kilobytes, and when running an already installed system, mount/fsck bomb with sig 11, after that you find yourself in single-user mode with every command (including 'reboot'!) yielding a SIGILL. Well, that chip is so broken by design, no software workaround can help its misery, a hardware fix exists, but cant (easily) be As Volker notes; Linux can work round it. So can OS/2. I don't know the details, but there ARE modes where it works. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Filesystem holes
: actually being used, while providing instant lookups.
:
: The single file would be about 96G addressable bytes... But the actual
: block count would be much lower. I suppose I will have to create a seri
es
: of these files and divide the problem into 4GB chunks, but one
: lookup/store will still be done with one calculation and one disk seek
: (just more filehandles open).
:
: Deletes seem problematic. My question is, does the operating system
: provide any way to free blocks used in the middle of a file?
:
: Must I periodically re-create these files (long and slow process, but no
t
: so bad if done infrequently) to reclaim space, or is there a way to free
: arbitrary blocks in a file in userland (WITHOUT trashing the filesystem?
: :-)
:
: - Ryan
:
: --
: Ryan Thompson [EMAIL PROTECTED]
: Network Administrator, Accounts
: Phone: +1 (306) 664-1161
:
: SaskNow Technologies http://www.sasknow.com
: #106-380 3120 8th St E Saskatoon, SK S7H 0W2
I would strongly recommend using a B+Tree instead of a hash table. Wit
h
a hash table slightly different lookups will seek all over the place.
With a B+Tree lookups will stay more localized.
Right... That's a good point, but (and, no, I really didn't mention this
in my original post), "sequential" access is never important with the
system I have described. Lookups are always random, and they are almost
always done one at a time (multiple lookups only done for data swaps...
very rare, like 1/1e7 accesses... and those are still O(1) (well,
O(2), but who's counting ;-)))...
Remember, though, I'm not proposing a hash table. I have been lucky
enough to design a "hash" function that will crunch down all possible
values into about 64M unique keys--so, no collisions. I propose to use
this function with address calculation. So, O(1) everything, for single
random lookups, which is (virtually) all this data structure must deal
with. Sorting isn't necessary, and that could be accomplished in O(n)
anyway.
Way to use has for variable-length records:
Use an intermediate 'file" whose records are simply pointers tot the location
of the real data.
Finding a record goes like this:
ACnumber=getRecord("KEY");
realRecordNumber=AC(ACnumber);
then read record number realRecordNumber.
AC I pinched from Adabas which (back in the early 80s, dunno what it does now)
had an address covertor. It changed record numers (returned by getRecord()
here) to a disk address. Its size is n, where n is the number of records you
support.
In data storage (andother Adabas term), you have fixed-length records, each
containing several records.
Adabas stored the Adabas record number and the data files; numbers stored as
binary, character fields (usually) preceded with a (one-byte) record size so
trailing spaces could be dropped.
Inserted records go into empty blocks (except in load mode where blocks are
filled to a user-specified percentage) (and presumably into a block in the
buffer pool with space).
Blocks are compressed before being rewritten - all the data is packed to the
front. The first field in the DS block is the offset to free space in the
block.
Adabas alsh had a work dataset, where data are recorded pending end of
transaction; EOT can be acknowldged when the information is safely recorded in
work as Adabas can always recover from there. It also has transaction logging,
either too tape (alternating with two drives) or two files on disk.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
