I recommend looking at some of the Multics features, particularly the use of segmentation and paging instead of a more normal file system.
see http://www.multicians.org/features.html for an introduction to Multics features and the references for how they really work. Multics was written to run on an SMP system so a system with 1 processor was the special case.

I would also suggest looking into security, again both the permissions an perhaps the ring based permission levels. The more the cpu can help with building in security from the start the easier it will be in the long run.

You might also want to look into the NS32xxx series from National Semiconductor in the late 80's/90's( not sure exactly when). The NS3200 all had the same instruction set, however you could get the chip with 8bit, 16bit, and 32bit memory/data access. At this stage of CPU's I'd suggest looking into detaching the instruction set from the 'bit' size so the external access to memory/data was independent of the bit size. With a 32 bit data/address bus it may take 2 transfers to handle a 64 bit data item, but that can be done by the hardware without the software having to know about it. All the software sees is a 64 bit (or maybe later on with added instructions a 128bit) address/data path with the actual path width hidden by the hardware. A 64 bit program might run a little slower on a 32 bit bus, but it will run.

If you are a computer science/computer geek type then it is probably a bad thing. If you are not involved in computer technology then it doesn't matter.

Have you ever heard of/used Multics?

I like readerware which also has programs to handle cd's and dvd's ad if you ave the isbn to download most of the information from te net.

http://www.readerware.com/ witch is Available for Windows, Linux, Mac OS X and Android. Not free, but I like it.

I have an older version that allows me to export to a old palm so I can take a copy with me when I go book shopping.

I can disagree with the dating there. I started working for Honeywell Federal Systems Operations in Nov 1977 on a project at Rome Air Development Center (RADC) called NSW (National software works). At the time I joined the project, email was used to communicate among the many vendors working on NSW including HIS/FSO (me on Multics), UCLA (IBM 360), RADC (DEC-20 and Multics), MCA/Compass, BBN, MIT (while they participated), and the Air Force (contractor). This was over the Arpanet and I believe I got my first spam either in 1977 or 1978 ;) These days, NSW might be considered an early cloud project.

The addresses were in the same form as current addresses, user@machine (there were no domains yet so each machine had a unique name).

I see a resurgence in folk music and classical music and anything no longer covered by copyright. I wonder how they will handle filksongs?

I worked for Honeywell from 1977 to 1979 in a multi-company ARPA contract. We exchanged informaton with all the other developers around the country via email. I can see him claiming to have written a specific email system for a specific purpose, but he did not invent email.

Go to a real office furniture company and get good chairs. don't go to Walmart, Officemax, Staples, etc. Back in 1995 I spent $600 to buy a heavy duty 24/7 office manager's chair. It came with a 12 year warranty. The chair is still in use.

I'd also suggest a comfy cot/lazy-boy/ez chair. I'm assuming there are multiple people on duty all the time. This allows one at a time to take a break away from the monitors.

You should make sure everyone can take a 10 minute break out of every hour to rest their eyes.

A company I worked for got around this by ordering all their hardware from dell and always specifying the same hardware so the drivers would be the same. The configured the first system to work the way they wanted with their MS server and then cloned the working drive for all the other workstations. All data was stored on the server. suspect an infected machine, reclone the drive.

Back when I was younger and a grad student I'd typically work 8 to 12 hours a day, 7 days a week on work projects, particularly when there were deadlines. I'd do this for several months at a time, meet the deadline, do some cleanup for a week and take a week off. Most of this was creating new code as I was developing software. I've done this for shorter times since then, like a few days at a time to solve problems for customers at another job. I've done the 8 to 12 hours/day 7 days a week for a couple months several times.

I'm now diabetic and have diabetic eye problems and can't focus on the computer screen well enough to reliably do more then around 10 hours computer work a week. I really miss the ability to program or read tech manuals.

The biggest problem I've been having with firefox is each of the last few releases seems to have become less stable then the one before it as well as taking a big performance hit. I think this may be the biggest challenge to firefox.

I think they need to take a break on adding/developing new features and take some time to do some serious bug stomping.

I'm starting to think about trying opera and/or chrome due to the crashing problems and sometimes erratic performance issues.

You may want to look more at Multics developed in the 60's. Multics was designed from start to run on multiple CPU's. Multics did not have a primary CPU, all were created/treated the same. Every 'process' ran basically in its own "virtual machine".

So far I've gotten along fine with my handspring prizm. For all the normal things I want something portable it does or has applications that will do the functions I want. The only time I really need more I want my full function laptop.

What the original post seems to be ignoring is the amount of 'data' stored with the block of data seen by the customer. It has been many years since I last looked into this so there may well be changes but:

A block of data consists of:

header/leader: this is alignment, block id, and other control information. at least 128 bytes

block of data: the data actually seen by the user

trailer: I don't remember the length, but probably close to the size of the header, but at least 64 bytes, probably 128. includes ecc and a second block id and other control information.

so assuming you have a track with a raw capacity of 1MB, just as an example:

512 byte blocks: 1,000,000/(128+512+128) = 1,000,000/768 = 1,302 blocks = 666,624 usable bytes out of 1,000,000 or 67%

4096 byte blocks: 1,000,000/(128+4096+128) = 1,000,000/4352 = 229 blocks = 937,984 usable bytes out of 1,000,000 or 94%

so the larger blocks make mush more efficient usage of the raw space. Even if the trailer becomes 512 bytes, the new utilization is 84%

In the proprietary system I used the BaSIC language was burned in ROM as the OS, no other languages. I've worked on other systems that did not have a C compiler or were sufficiently unique that the 'generic' tools would not work. I've even seen some generic tools blow up due to some of the bad programming used and/or not be able to figure out what was going on.

I'm not saying that the person should always write their own tools. If the generic ones aren't available or don't work for whatever reason, writing some of your own to help can be a bonus in the long run.

Sometimes having tools that know more about your specific environment can be more helpful. Sometimes the information you want isn't something available from a generic tool.