Slashdot Mirror

Going back to our Latin roots:....

A good site for the mreanings of Latin Names of plants is Dictionary of Botanical Epithets.

I've taken these names and incorperated them in the Plants For A Future Database of useful plants.

Yet another slashdot ripping to shreds, (it does seem to be a good forum for that). Like attracts like, slashdot attracts anti MS, lame jokes, with the occasional flash of inspiration. The moderation system while good at filtering out the dross can help keep the party line.

I just had two years away from slashdot at it seems to have dropped in quality. Two years ago reading at 4/5 would give me the most interesting comments, normally about 10 which is enough to really cover most points in a discussion. Now your typical item is getting 30-40 in the 4/5 level. And I never get to the end of the list as I get board by the repeated discussion. Have a look at the number of comments in Do You Write Backdoors? thread. 37 at 5, 52 at 4, 86 at 3, 220 at 2, 368 at at 1 and 531 at 0. The ratio of these are

• 37/52 = .7 5 vrs 4
• 52/86 = .6 4 vrs 3
• 86/220 = .4 3 vrs 2
• 220/368 = .7 2 vrs 1

I'd like to see a sharper drop, so its only the really good comments which get to be 5. This is possibly achievable by reducing the number of moderation points around.

I'm with Joel on quoting. I almost never quote and do not enjoy the pickyness in usenet. This may be my personal preferance, I tend to prefer quick overviews to small details.

He's certainly right on how small design changes affect the type of discussion. I've done several small changes my own discussion board at Plants For A Future (which is really a means for adding corections to pages rather than a true discussion board). Originally you had to go to a new page to add a comment, I wanted to encourage more posts and also to make it easier for people to add links to other sites with related info. So put the reply box right there on the page and add a box so people can easily add a link without having to know about all that &lta href stuff. Sure enough number of links went up.

Just thinking of my dream discussion board software. All these small changes could be easily configurable so that you create the kind of discussion you want.

Now I'm going to go away and remove that followup link from my board. The feature never worked well anyway.

ttfn Rich

Yet another slashdot ripping to shreds, (it does seem to be a good forum for that). Like attracts like, slashdot attracts anti MS, lame jokes, with the occasional flash of inspiration. The moderation system while good at filtering out the dross can help keep the party line. I just had two years away from slashdot at it seems to have dropped in quality. Two years ago reading at 4/5 would give me the most interesting comments, normally about 10 which is enough to really cover most points in a discussion. Now your typical item is getting 30-40 in the 4/5 level. And I never get to the end of the list as I get board by the repeated discussion. Have a look at the number of comments in Do You Write Backdoors? thread. 37 at 5, 52 at 4, 86 at 3, 220 at 2, 368 at at 1 and 531 at 0. The ratio of these are 37/52 = .7 52/86 = .6 86/220 = .4 220/368 = .7 So 70% of posts with 4 get moderated up to 5. We see a big drops from 2 to 3 and small drops from 4 to 5. I'd like to see a sharper drop, so its only the really good comments which get to be 5. This is possibly achievable by reducing the number of moderation points around. I'm with Joel on quoting. I almost never quote and do not enjoy the pickyness in usenet. This may be my personal preferance, I tend to prefer quick overviews to small details. He's certainly right on how small design changes affect the type of discussion. I've done several small changes my own discussion board at Plants For A Future (which is really a means for adding corections to pages rather than a true discussion board). Originally you had to go to a new page to add a comment, I wanted to encourage more posts and also to make it easier for people to add links to other sites with related info. So put the reply box right there on the page and add a box so people can easily add a link without having to know about all that &lta href stuff. Sure enough number of links went up. Just thinking of my dream discussion board software. All these small changes could be easily configurable so that you create the kind of discussion you want. Now I'm going to go away and remove that followup link from my board. The feature never worked well anyway. ttfn Rich

I agree. Building your own chemistry set would be more fun, and you would learn more.

The best way to learn is to teach. Collecting a bunch of good chemistry experiments, and the sources for the materials, would make a great project.

And you aren't the only one who benefits...

Some places to start:
Delights of Chemistry
Demonstration Lab
Lecture Demonstrations
Chemistry Resources

Some Sources of chemicals:
CHEM Scientific
Fisher
Sagent Welch
Carolina

I am certain you will get lots more from other Slashdaughters...

Last year I caught a Nature special (or something) regarding the Indoenesian Mimic Octopi that caught my attention like no other creature ever had before!
It's capable of mimicking a crab, sea snake, flounder, lionfish, and other species have other abilities. Absolutely floored me.

I think that "IN UNDERSEA INDONESIA, OCTOPI GENETICALLY MANUPULATE THE EXTRA-TERRESTRIALS."

GSM uses an encryption algorithm called A5 which is fairly weak, with an effective key length of at most 5 bytes.

As this page says, "A5 is a stream cipher, and the keystream is the xor of three clock
controlled registers. The clock control of each register is that register's
own middle bit, xor'ed with a threshold function of the middle bits of all
three registers (ie if two or more of the middle bits are 1, then invert
each of these bits; otherwise just use them as they are). The register
lengths are 19, 22 and 23, and all the feedback polynomials are sparse.
... there is a trivial 2^40 attack (guess the contents of
registers 1 and 2, work out register 3 from the keystream, and then step on
to check whether the guess was right). 2^40 trial encryptions could take
weeks on a workstation, but the low gate count of the algorithm means that
a Xilinx chip can easily be programmed to do keysearch, and an A5 cracker
might have a few dozen of these running at maybe 2 keys per microsecond
each." There is some code as well for the crack itself.

Enjoy!

There's a huge amount of open-source NLP resources and software for many languages on the web.

• Thought Treasure - a bilingual database of 25000 concepts including 55000 English and French words and phrases. Compiles under Linux and Windows

• Leeds University NLP Research Group (mail webmaster re broken links to software)

• Japan's ICOT/5th Generation Computer Project archive of free software

• Linguistics Toolset at Vaasa University

Last but not least:

• A well-annotated collection of NLP links including NLP, NLU, Speech*, MLT, Fuzzy*, MLPs, SVMs, etc

Will.

This tells you about A5; the encryption used in GSM phones.

"Gaol" is English for a place used for the incarceration of "criminals". Americans call it "The Hoosegow", "The joint", "The big house", "Pokie", "The Slammer", amongst other things.

Code quality actually improves with longer hours. It was recently proven that:

cq = hw * k

where cq is code quality, hw is hours worked, and k is a constant which is roughly equal to pi/e.

Recent papers in related fields definitively shows that late hours and working long weekends maintains productivity, and, in fact, can actually increase the value of k in the above equation.

For crying out loud, doesn't anyone do their research before posting on Slashdot?!

Oh, yeah, and you spelled "affect" wrong, in case nobody mentioned it.

-_-_-

Here is a site about the pathway sialic acid took through human cells. Its a bit confusing, but informative never-the-less. And here is a PDF of the basic functions of sialic acid. It also has a bit on directed evolution.

UBC: An Efficient Unified I/O and
Memory Caching Subsystem for NetBSD

Chuck Silvers
The NetBSD Project
chuq@chuq.com, http://www.netbsd.org/

Abstract

This paper introduces UBC ("Unified Buffer Cache"), a design for unifying the filesystem and virtual memory caches of file data, thereby providing increased system performance. In this paper we discuss both the traditional BSD caching interfaces and new UBC interfaces, concentrating on the design decisions that were made as the design progressed. We also discuss the designs used by other operating systems to solve the same problems that UBC solves, with emphasis on the practical implications of the differences between these designs. This project is still in progress, and once completed will be part of a future release of NetBSD.

Introduction

Modern operating systems allow filesystem data to be accessed using two mechanisms: memory mapping, and I/O system calls such as read() and write(). In traditional UNIX-like operating systems, memory mapping requests are handled by the virtual memory subsystem while I/O calls are handled by the I/O subsystem. Traditionally these two subsystems were developed separately and were not tightly integrated. For example, in the NetBSD operating system[1], the VM subsystem ("UVM"[2]) and I/O subsystem each have their own data caching mechanisms that operate semi-independently of each other. This lack of integration leads to inefficient overall system performance and a lack of flexibility. To achieve good performance it is important for the virtual memory and I/O subsystems to be highly integrated. This integration is the function of UBC.

Background

In order to understand the improvements made in UBC, it is important to first understand how things work without UBC. First, some terms:

• "buffer cache":

  A pool of memory allocated during system startup which is dedicated to caching filesystem data and is managed by special-purpose routines.

  The memory is organized into "buffers," which are variable-sized chunks of file data that are mapped to kernel virtual addresses as long as they retain their identity.

• "page cache":

  The portion of available system memory which is used for cached file data and is managed by the VM system.

  The amount of memory used by the page cache can vary from nearly 0% to nearly 100% of the physical memory that isn't locked into some other use.

• "vnode":

  The kernel abstraction which represents a file.

  Most manipulation of vnodes and their associated data are performed via "VOPs" (short for "vnode operations").

The major interfaces for accessing file data are:

• read() and write():

  The read() system call reads data from disk into the kernel's cache if necessary, then copies data from the kernel's cached copy to the application's address space. The write() system call moves data the opposite direction, copying from the application's address space into the kernel's cache and eventually writing the data from the cache to disk. These interfaces can be implemented using either the buffer cache or the page cache to store the data in the kernel.

• mmap():

  The mmap() system call gives the application direct memory-mapped access to the kernel's page cache data. File data is read into the page cache lazily as processes attempt to access the mappings created with mmap() and generate page faults.

In NetBSD without UBC, read() and write() are implemented using the buffer cache. The read() system call reads file data into a buffer cache buffer and then copies it to the application. The mmap() system call, however, has to use the page cache to store its data since the buffer cache memory is not managed by the VM system and thus not cannot be mapped into an application address space. Therefore the file data in the buffer cache is copied into page cache pages, which are then used to satisfy page faults on the application mappings. To write modified data in page cache pages back to disk, the new version is copied back to the buffer cache and from there is written to disk. Figure1 shows the flow of data between the disk and the application with a traditional buffer cache.

This double-caching of data is a major source of inefficiency. Having two copies of file data means that twice as much memory is used, which reduces the amount of memory available for applications. Copying the data back and forth between the buffer cache and the page cache wastes CPU cycles, clobbers CPU caches and is generally bad for performance. Having two copies of the data also allows the possibility that the two copies will become inconsistent, which can lead to application problems which are difficult to debug.

The use of the buffer cache for large amounts of data is generally bad, since the static sizing of the buffer cache means that the buffer cache is often either too small (resulting in excessive cache misses), or too large (resulting in too little memory left for other uses).

The buffer cache also has the limitation that cached data must always be mapped into kernel virtual space, which puts an additional artificial limit on the amount of data which can be cached since modern hardware can easily have more RAM than kernel virtual address space.

To solve these problems, many operating systems have changed their usage of the page cache and the buffer cache. Each system has its own variation, so we will describe UBC first and then some other popular operating systems.

So what is UBC anyway?

UBC is a new subsystem which solves the problems with the two-cache model. In the UBC model, we store file data in the page cache for both read()/write() and mmap() accesses. File data is read directly into the page cache without going through the buffer cache by creating two new VOPs which return page cache pages with the desired data, calling into the device driver to read the data from disk if necessary. Since page cache pages aren't always mapped, we created a new mechanism for providing temporary mappings of page cache pages, which is used by read() and write() while copying the file data to the application's address space. Figure2 shows the changed data flow with UBC.

UBC introduces these new interfaces:

• VOP_GETPAGES(), VOP_PUTPAGES()

  These new VOPs are provided by the filesystems to allow the VM system to request ranges of pages to be read into memory from disk or written from memory back to disk. VOP_GETPAGES() must allocate pages from the VM system for data which is not already cached and then initiate device I/O operations to read all the disk blocks which contain the data for those pages. VOP_PUTPAGES() must initiate device I/Os to write dirty pages back to disk.

• ubc_alloc(), ubc_release()

  These functions allocate and free temporary mappings of page cache file data. These are the page cache equivalents of the buffer cache functions getblk() and brelse()[3]. These temporary mappings are not wired, but they are cached to speed repeated access to the same file. The selection of which virtual addresses to use for these temporary mappings is important on hardware which has a virtually-addressed CPU data cache, so the addresses are carefully chosen to be correctly aligned with the preferred addresses for user file mappings, so that both kinds of mappings can be present at the same time without creating coherency problems in the CPU cache. It is still possible for applications to create unaligned file mappings, but if the application lets the operating system choose the mapping address then all mappings will always be aligned.

• ubc_pager

  This is a UVM pager which handles page faults on the mappings created by ubc_alloc(). (A UVM pager is an abstraction which embodies knowledge of page-fault resolution and other VM data management. See the UVM paper[2] for more information on pagers.) Since its only purpose is to handle those page faults, the only action performed by ubc_pager is to call the new VOP_GETPAGES() operation to get pages as needed to resolve the faults.

In addition to these new interfaces, several changes were made to the existing UVM design to fix problems which were glossed over in the original design.

Previously in UVM, vnodes and uvm_objects were not interchangeable, and in fact several fields were duplicated and maintained separately in each. These duplicate fields were combined. At this time there's still a bit of extra initialization the first time a struct vnode is used as a struct uvm_object, but that will be removed eventually.

Previously UVM only supported 32-bit offsets into uvm_objects, which meant that data could only be stored in the page cache for the first 4 GB of a file. This wasn't much of a problem before since the number of programs which wanted to access file offsets past 4 GB via mmap() was small, but now that read() and write() also use the page cache interfaces to access data, we had to support 64-bit uvm_object offsets in order to continue to allow any access to file offsets past 4 GB.

What do other operating systems do?

The problems addressed by UBC have been around for a long time, ever since memory-mapped access to files was first introduced in the late 1980's. Most UNIX-like operating systems have addressed this issue one way or another, but there are considerable differences in how they go about it.

The first operating system to address these problems was SunOS[4,5], and UBC is largely modeled after this design. The main differences in the design of the SunOS cache and UBC result from the differences between the SunOS VM system and UVM. Since UVM's pager abstraction and SunOS's segment-driver abstraction are similar, this didn't change the design much at all.

When work on UBC first began over two years ago, the other design that we examined was that of FreeBSD[6], which had also already dealt with this problem. The model in FreeBSD was to keep the same buffer cache interfaces to access file data, but to use page cache pages as the memory for a buffer's data rather than memory from a separate pool. The result is that the same physical page is accessed to retrieve a given range of the file regardless of whether the access is made via the buffer cache interface or the page cache interface. This had the advantage that filesystems did not need to be changed in order to take benefit from the changes. However, the glue to do the translation between the interfaces was just as complicated as the glue in the SunOS design and failed to address certain deadlock problems (such as an application calling write() with a buffer which was a memory mapping of the same file being written to), so we chose the SunOS approach over this one.

The approach taken by Linux[7] (as of kernel version 2.3.44, the latest version at the time this paper was written) is actually fairly similar to the SunOS design also. File data is stored only in the page cache. Temporary mappings of page cache pages to support read() and write() usually aren't needed since Linux usually maps all of physical memory into the kernel's virtual address space all the time. One interesting twist that Linux adds is that the device block numbers where a page is stored on disk are cached with the page in the form of a list of buffer_head structures. When a modified page is to be written back to disk, the I/O requests can be sent to the device driver right away, without needing to read any indirect blocks to determine where the page's data should be written.

The last of the operating systems we examined, HP-UX, takes a completely different stance on the issue of how to cache filesystem data. HP-UX continues to store file data in both the buffer cache and the page cache, though it does avoid the extra of copying of data that is present in pre-UBC NetBSD by reading data from disk directly into the page cache. The reasoning behind this is apparently that most files are only accessed by either read()/write() or mmap(), but not both, so as long as both mechanisms perform well individually, there's no need to redesign HP-UX just to fix the coherency issue. There is some attempt made to avoid incoherency between the two caches, but locking constraints prevent this from being completely effective.

There are other operating systems which have implemented a unified cache (eg. Compaq's Tru64 UNIX and IBM's AIX), but we were unable to find information on the design of these operating systems for comparison.

Performance

Since UBC is unfortunately not yet finished, a detailed performance analysis would be premature. However, we have made some simple comparisons just to see where we stand. The hardware used for this test was a 333MHz Pentium II with 64MB of RAM and a 12GB IDE disk. The operations performed were a series of "dd" commands designed to expose the behaviour of sequential reads and writes. We create a 1GB file (which is much larger than the physical memory available for caching), then overwrite this file to see the speed at which the data modifications caused by the write() are flushed to disk without the overhead of allocating blocks to the file. Then we read back the entire file to get an idea of how fast the filesystem can get data from the disk. Finally, we read the first 50MB of the file (which should fit entirely in physical memory) several times to determine the speed of access to cached data. See Table 1 for the results of these tests.

The great disparity in the results of the first four tests on the three non-UBC operating systems is due to differences in performance of their IDE disk drivers. All of the operating systems tested except NetBSD with UBC do sequential buffered reads from a large file at the same speed as reads from the raw device, so all we can really say from this is that the other caching designs don't add any noticable overhead. For reads, the UBC system is not yet running at device speed, so there's still room for improvement. Further analysis is required to determine the cause of the slowdown.

UBC obviously needs much improvement in the area of write performance. This is partly due to UVM not being very efficient about flushing modified pages when memory is low and partly because the filesystem code currently doesn't trigger any asynchronous writes to disk during a big sequence of writes, so the writes to disk are all started by the inefficient UVM code. We've been concentrating on read performance so far, so this poor write performance is not surprising.

The interesting part of this test series is the set of tests where we read the same 50MB file five times. This clearly shows the benefit of the increased memory available for caching in the UBC system over NetBSD without UBC. In NetBSD 1.4.2, all five reads occured at the speed of the device, whereas in all the other systems the reads were completed at memory speed after several runs. We have no explanation for why FreeBSD and Linux didn't complete the second 50MB read at memory speed, or why Linux didn't complete even the third read at memory speed.

Conclusion

In this paper we introduced UBC, a improved design for filesystem and virtual memory caching in NetBSD. This design includes many improvements over the previous design used in NetBSD by:

• Eliminating double caching of file data in the kernel (and the possibility of cache incoherency that goes with it) when the same file is accessed via different interfaces.

• Allowing more flexibility in how physical memory is used, which can greatly improve performance for applications whose data fits in physical memory.

Availability

This work will be part of a future release of NetBSD once it is completed. Until then, the source code is available in the "chs-ubc2" branch in the NetBSD CVS tree, accessible via anonymous CVS. See http://www.netbsd.org/Sites/net.html for details.

This being a work-in-progress, there is naturally much more work to do! Planned work includes:

• Integration of UBC into the NetBSD development source tree and performance improvement. The pagedaemon needs to be enhanced to deal with the much larger amount of page-cache data which will be dirty.

• Elimination of the data copying in read() and write() via UVM page loanout when possible. This could be done without UBC too, but with UBC it will be zero-copy instead of one-copy (from buffer cache to page cache).

• Elimination of the need to map pages to do I/O to them by adding a page list to struct buf and adding glue in bus_dma to map pages temporarily for hardware that actually needs that.

• Adding support for "XIP" (eXecute In Place). This will allow zero-copy access to filesystem images stored in flash roms or other memory-mapped storage devices.

• Adding support for cache coherency in layered filesystems. (The current UBC design does not address caching in layered filesystems.)

Acknowledgments

We would like to thank everyone who helped review drafts of this paper. Special thanks to Chuck Cranor!

Bibliography

1 The NetBSD Project.
The NetBSD Operating System.
See http://www.netbsd.org/ for more information.

2 C. Cranor and G. Parulkar.
The UVM Virtual Memory System.
In Proceedings of the 1999 USENIX Technical Conference, June 1999.

3 Marice J. Bach.
The Design of the UNIX Operating System.
Prentice Hall, February 1987.

4 J. Moran, R. Gingell and W. Shannon.
Virtual Memory Architecture in SunOS.
In Proceedings of USENIX Summer Conference, pages 81-94. USENIX, June 1987.

5 J. Moran.
SunOS Virtual Memory Implementation.
In Proceedings of the Spring 1988 European UNIX Users Group Conference, April 1988.

6 The FreeBSD Project.
The FreeBSD Operating System.
See http://www.freebsd.org/ for more information.

7 L. Torvalds, et al.
The Linux Operating System.
See http://www.linux.org/ for more information.

About this document ... UBC: An Efficient Unified I/O and
Memory Caching Subsystem for NetBSD

This document was generated using the LaTeX2HTML translator Version 98.1p1 release (March 2nd, 1998)

Copyright 1993, 1994, 1995, 1996, 1997, Nikos Drakos, Computer Based Learning Unit, University of Leeds.

The command line arguments were:
latex2html -split 0 -no_navigation ubc_usenix.

The translation was initiated by Chuck Cranor on 2000-04-25
Chuck Cranor
2000-04-25

This isn't the only project out there which has suddenly found their digital data is no longer readable. It is a growing problem, and the Microsoft file format mentality really isn't going to help in the next 5-10 years.

There are other projects out there that aim to help people work aroud them. One of the bigger being Cedars, which is dedicated to helping people plan for their digital data acquisition, formatting, storage and cataloging.

With GSM you need to be able to grab the entire range of spectrum and the you can put the parts back to gether later. Grabbign all the spectrum is too expensive for the amature crowd but with some of the million channel recivers like the ones used for SETI, its trival. One would assume the spooks know about this type of device.

GSM crypto isn't very good. Its about keeping people from getting the data in real time. Computers have gotten much faster since it was invented. The article mentions 2 keys per microsecond. A modern attack of the type mentioned could do 2 per nanosecond using a simple off the shelf programable logic array for a key in under 5 minutes 1/2 of the time. Remember the phone comapny has one of the keys and may be transmitting them out as well.

Actually you are oxidizing sugars, just like this experiment does. Check demonstration 33, which mentions this (although in that case they're just burning with liquid oxygen).

I seem to remember a friend doing this in Chem II class in high school, and getting detention for a week in the process.

The Giant Artificial Poo! Although if you have sulfuric acid in your digestive tract, you're more of a man then I am.

I also remember another demonstration in which he blew the lid of a can. I can't remember what he did then though.

Probably blew lycopodium into a can that had a lit candle in it. Classic experiment. Mr Wizard did this one on his show (he did a lot of stuff with lycopodium). You can get details from the site here.

I think you have a typo and you meant it to be this

But then while you are at it, why not try a Python tutorial.

Here ya go.

and this story describes how they arrived at the sound...

ahh the wonders of leeds' search engine...

and this story describes how they arrived at the sound...

ahh the wonders of leeds' search engine...

The University of Leeds has been doing this for a while it seems... mod date on this is September 2000

In my experience University email systems aren't the most reliable in the world though ;o)

--

If only. They've got a face recognition system called Mandrake already in use in the London Borough of Newham, and a traffic monitoring system (TrafficMaster) using number-plate recognition, currently only to gauge average speeds for traffic flow, but since it works by recognising the vehicles, it certainly counts. There's also a very clever system in development by the Uni's of Leeds and Reading which uses a neural net to identify pedestrians behaving 'suspiciously'.

Big Brother's already hard at work.

TomV

SLab is an excellent multitrack recorder/mixer. It is not up to snuff with ProTools yet (though no program is on any platform).

Other Linux audio related links include (sorry if some links are bad, I haven't updated this list in awhile):

Multitrack audio recording/mixing:
Ardour
Slab
Snd

Midi Sequencing:
Jazz++
Rosegarden
Brahms (I THINK this is a sequencer)

Sound editing / effects processing:
MixViews
ecasound

Audio creation (synth emulators):
Ultramaster RS-101 and Juno6 CSound
Cecilia (requires Csound)

Notation:
Lilypond
Rosegarden
Mup

Awesome pages with links to everything you wanted to know about Linux audio:
Applications for Open Sound System
Sound and MIDI software for Linux

There is some work that is already in progress for integrating TeX (and LaTeX) with the Web. One procedure is to convert LaTeX to HTML - done by programs like latex2html . What the original post is asking for - is done by HyperTeX.

One reason that LaTeX would not be popular is the way it forces you to write well structured documents - something that can be done in HTML if you wish, but you won't be forced to do so. The more common objection to LaTeX - cryptic commands and no WYSIWYG editor - LyX provides a decent enough WYSIWYG editor.

I actually have a bookmark to this page of Transport Research links. If you're not looking for research, there's a wider assortment at Yahoo's Transportation Page.

Usually they are OK with html. You can get a latex2html converter from http://cbl.leeds .ac.uk/nikos/tex2html/doc/latex2html/latex2html.ht ml.

Academic institutions in general, to a greater or lesser extent, have to devise more flexible and efficient learning and teaching strategies.

Financial constraints, flexible modes of study, increasing student numbers and reduced contact time between students and lecturers has led to the recognition of the need to adopt new technologies to increase the efficiency and effectiveness of available resources

Students are increasingly being made to use web based learning instead of the traditional lecture/seminar routine. The push over here is from the government that Academic institutions make 'affordable access' to portable computers so that students off-campus have equal access to resources.

The Report of the National Committee of Inquiry into Higher Education (Dearing Report) in the UK studied in depth the use of Computers and Information Technology in Higher Education.

Recommendation 46 was that we "expect that by 2005/06 all students (in the UK) will be required to have access to their own portable computer".
For info on the dearing report click here
For the recommendations of the dearing report click here
To learn more about learning and teaching click here
and a good article on the future of learning click here

That's the principle that the Leeds University archiver works on. As the tapes are continuously getting bigger, if the system is set up semi-automatically, data can be continually transferred to current media without significant time expenditure. The ISS reckon this can continue pretty much indefinitely.

--
Tom Harris
http://www.harris.ukgateway.net

But I wouldn't be too sure.

How does this one get through, potentially? They bring out small kids who lost small siblings to speeding drivers. End of story. That's the way the British public's been trained to react by the media.

The problem is that we've got a heavily tabloid culture and not that high civil liberties respect. Our Labour Home Secretary (Jack Straw) has been putting out illiberal legislation for most of his term in office, but most people just don't notice.

This is horrible, short-sighted and probably trying to drum up publicity for the department at Leeds University who did the research. I really hope it doesn't get through, but I don't hold out much hope.

To stop (some of) the flames, why do I think I should be allowed to speed? Several things. Firstly, let's imagine I'm overtaking someone on a single carriageway road. Is this safer if I do it more slowly? No. It's safer (up to a point) at higher speed because I spend more time on the right side of the road and not on a collision course. Speeding briefly makes it a far safer maneuver. And if I don't pass, I'm potentially helping build a tailback - so causing air and noise pollution and frustration, so more accidents.

Next, look at how this works. It cuts off the fuel. Imagine what happens if it fails - the car dies, and there may well be nothing you can do to fix it short of calling out a repair technician. One more thing that I can't fix but that can strand me is dangerous.

Next, it perpetuates the myth that speed is the only problem. Police research shows speed is the primary cause in under 5% of accidents. But if there's a limiter, I'm safe, right? As it's speed that kills.

Now look at Japan. All cars are limited to 112, in theory. So, backstreet tuners hack the limiters away, with varying degrees of finesse. Some do a good job, sure. But is it really a good idea to encourage people to reprogram their cars? Because that's just what people will do to get round this, but it potentially introduces new bugs. Not pretty.

Finally, there's the fairly obvious civil liberties thing - not that I should be permitted to speed, as I'm happy with sensible law enforcement. It's more that this makes vehecile tracking extremely easy and, regardless of how legal my movements are, they're my business. I know they can be tracked to a fair degree via CCTV, but this would make it trivial.

What would I do? Jaguar have a new Adaptive Cruise Control system. Basically, there's an ultrasound system in the front bumper so that the cruise control system can keep you a sensible distance from the car in front. Build that into every car, linked to the speedo to determine sensible gaps, and I wouldn't complain. But this system is a very bad idea, which deserves to be fought.

Greg

Disney's most visible technological showpieces often had to do with transportation. He understood that packing too many humans into a small space caused problems; that people weren't tempermentally suited to it. His generation's solution to the problem of overcrowding in the cities was to spawn suburbs (i.e. dilution). The resulting transportation problems begged for technological solutions... and his visionaries produced.

Disney then displayed these technological marvels in parks where people were packed into a space too small for comfort with thousands of strangers. Instead of applying the "suburb and transportation" model inside the parks, Disney used far more subtle technologies to allow people to rub up against one another with less friction, less rage.

It appears to me that the urban plan of the future is to re-centralize cities. Better and better roads/rail/etc. have just caused more sprawl and the result is that the capacity of those roads/rails/etc. has been saturated, usually as soon as they are built. Now the move appears to be the other way. For example, the techniques of traffic calming (at least how it's practiced in this corner of Canada) seem aimed at making the commute sufficiently intolerable that it will discourage folks from seeking "the good life" in the 'burbs, thus reducing traffic, pollution, etc.

Personally, I usually find crowds to be intolerable. I found Disney{land|world} to be crowded, but tolerable. But on my last trip to Disney, on a hot, August afternoon, I took a break and ate in a (simulated) New Orleans cafe with (simulated) stars in a clear, (simulated) sky, while (live) music played softly from a balcony and (live) people in boats drifted by on a (simulated) stream. Despite the presence of the (simulated) swamp, nearby, there were no (simulated or real) mosquitoes. It was a beautiful example of total environmental control (light, season, location, sound, temperature, insects, etc.) not dissimilar to the contrived environments at the Museum of Civilization (Hull, Quebec) or the Museum of Natural History (Winnipeg, Manitoba).

They had produced an environment that calmed. That soothed. That manipulated me into thinking that I wasn't in a crowd.

And it did it by applying some heavy duty (and nearly invisible) technology, and applying it well.

...and (I find this ironic) this is not the technology that is on display!

I ask for flaws that you want presented and you can only come up with straw men like those?

Here, let me direct you at a reference for why there are and always will be gaps in the fossil record. And as for the birds, are you thinking of the se gulls? In which case your comment about dissecting the things is completely wrong. And while they make an extremely nice example, first of all do not be fooled into thinking that they are the only ring species. Besides which, there are lots of other reasons to believe in macro evolution. Or perhaps you forget what led Darwin to look at the theory of evolution?

Right, something completely different.

I am still waiting for a flaw that we are supposed to teach...

Ben

I was wondering about the possability of building a "Digital Recording Studio" that was capable of making some reasonable quality recordings. Something that would take seperate tracks at seperate times, so you could lay down a drum beat, then come back and add in the instruments, then the vocals, etc.. I would prefer to do it in Linux or FreeBSD, and with open source software (for financial reasons), but unfortunately I think I will end up with something commercial. (I am not going to pop for a $10,000+ system and software).

I was checking out GreenBox and Studio but don't really know anything about them yet, it's just all I found for Linux, and would like to hear from some people that can speak from experiance about thier functionality, ease of use, etc... And, I wouldn't mind hearing about some hardware requirements, would it take gobs and gobs of RAM and SCSI drives and massive CPU power to do playback of a track while recording another track to sync to it?

I would really appreciate learning more about how possable this is, and how expnsive it might be... Maybe an old 4-track unit that allows you to do this with normal cassette tapes would be something to consider for me to play around with, but it would really be a lot more fun if I could get digital quality, and have a little more precise control, and be able to do it on a computer, create MP3's etc...