If you're worried about a leak damaging your computer, you could always use vegetable oil as your coolant. Heat capacity isn't as good, and you'll have to take off the heat sink assembly and flush it with soapy water every few months, but it's better than air and won't damage electronics if there is a leak.
Many other possible coolants exist; just bear in mind that you don't want your coolant to be very flammable (so something like kerosene is not an option, despite lower viscosity).
While waiting for the article to load, I did back-of-the-envelope calculations for the performance of the best possible 1 kg computer with atom-sized features.
In case anyone else is as bored as I was, here are the calculations and the numbers:
- Assume, arbitrarily, that your device is made of carbon and has one computing element (gate or memory element) per 10 atoms, average. This gives a total of about (1000 / (12 * 10)) * 6e23 = 5e24 computing elements.
- Assume that we're going for floating-point performance, and are using most of our elements for multiplication units. Assume we're cheating and using single-precision ints (32 bits). If we're allowed to pipeline arbitrarily deeply (we're runnign a toy benchmark program), then it would take somewhere in the realm of 4000 computing elements to build an IEEE-compliant floating point multiplier. This gives us 5e24/4000 = 1.25e21 multiplication units operating in parallel.
- Assume that we're signalling using light and that the light has to travel 1 nm per clock (we're very good at routing traces). This gives a clock frequency of 3e8/1e-9 = 3e17 Hz.
- This gives us a total of 1.25e21 x 3e17 = 3.75e38 FLOPS. Less than the best, but still not too shabby.
For kicks, let's compute the power requirements of this device.
- Assume that on every clock, half of the computation units change state (we're managing to use all of the computation units all of the time, with random data). This gives 5e24 / 2 = 2.5e24 transitions per clock.
- This gives 2.5e24 * 3e17 = 7.5e41 transitions per second.
- Assume that each transiton costs about 5 eV in total (split this however you like). This gives 5 eV * 1.6e-19 J/eV = 8e-19 Joules per transition.
- This gives us a power dissipation of 6e23 watts. A bit power-hungry.
For kicks, let's compute the surface temperature of this computer assuming radiative cooling:
- Assume that our computer is a 10-cm cube, with a density comparable to that of water (this is strangely-structured carbon). This gives us a surface area of 6e-2 square metres.
- Radiative energy emission from the object will therefore be equal to 6e-2 * 5.67e-8 * T^4 = 3.46e-9 * T^4 watts, where T is the object's surface temperature.
- For a power dissipation of 6e23 watts, the object's surface temperture would be (6e23 / 3.46e-9) ^ (1/4) = 1.15e8 degrees Kelvin. A bit warm.
Summary of data for the best possible nanotech computer:
5e24 computing elements.
3.75e38 FLOPS (single-precision multiplies).
3e17 Hz.
6e23 watts.
Surface temperature of 1.15e8 degrees Kelvin.
Looks like we'd have to underclock this baby.
Derivation of computing power for a comparably-sized quantum computer is left as an exercise for the reader.
In practice, we'd probably wind up building our nanocomputers as thin films with a lot less computing power but far lower power dissipation. Possibly as nano-grains, also, depending on application.
If your company is liable for any email originating from it, then a logical solution is to block outgoing email from most users. Give the company a few official contact people who talk to clients directly, and act as go-betweens for other work-related email.
Non-work-related email can be handled through home accounts, POP3 to an employee's ISP's mail server, web mail, or what-have-you.
This is draconian, but it does virtually eliminate the problem of liability for outgoing email. Internal email management is left as an exercise to the reader.
I can rattle off lots of processors that are more efficient than x86 (RISC processors such as PA-RISC, MIPS, SPARC, DEC Alpha ARM, etc.)
Most of these processors aren't appropriate for a gaming platform.
PA-RISC, SPARC, and Alpha chips are workstation-class and priced accordingly. They'd cost at least as much as the retail price of your console - not something you can use.
ARM chips have horrible FP performance (the older versions didn't even have an FPU). This is a deliberate design trade-off; having only integer operations lets you save a lot of silicon and a lot of power. But gaming consoles need floating-point big time for physics, 3D collision detection, and any transformations that aren't handled by the hardware (there will be many). So this too is not something you can use.
MIPS chips would be an acceptable choice - if you license the core and fab your own chips. But this is expensive, and leads to more effort required in the motherboard design as well. You can do this if you're a console company and are optimized for it - but Microsoft isn't on either count.
So Intel looks like the best choice for Microsoft just from a price and design effort point of view.
remember NT came out originally for MIPS, Intel and Alpha. Mips and Alpha are long gone
And this is another *VERY* big reason for Microsoft to use Intel chips - they don't need to rewrite their operating system from scratch for a new platform. That would take a horrific amount of work, especially since they're porting DirectX as well as the OS itself.
A gaming console must do one thing and it must do it well, which screams RISC to me
Modern CISC-ish processors are just as efficient. Instruction decoding is a little hairier, but that's pretty much a solved problem. This is the old "CISC decoder with a RISC core" description that you've been hearing for both Intel and AMD chips (not precisely accurate, but close enough).
The big flaw in Intel chips is that it has few general-purpose registers, but so far the chips have held up without a vast performance gap.
I've read the article over at Ars on the Emotion Engine and it looks like if software developers can get their heads around it, the Playstation 2 should lay waste to the Xbox.
The Playstation 2 is nice, but still have a few serious design flaws. The fact that it has only a miniscule amount of frame buffer memory is the most obvious of these, but I'm a bit skeptical of the bus as well.
Realistic performance figures that I've heard for the Playstation put the X-box ahead (not surprising, as it has a graphics chip that's a couple of generations later than the Playstation, due to a later release date).
Software optimization *should* be a solved problem if Sony writes or has written, say, an OpenGL implementation optimized for their hardware.
I'm not a big fan of the X-box, but I'm afraid that I disagree with several of the points you use in your argument against it.
Which would make a better OS for a software synthesizer:
The simple answer: Whichever platform has the software already existing for it (at least if you need to use it in the near future).
The ideal situation would seem to be an OS that has the graphical capability to present an interface for MAKING instruments, and then a working capability where the graphics are gone and you PLAY the instruments. Whizbang stuff for building the instruments, and simple multitimbral interface for using the built instruments.
All of the OSes you listed are _capable_ of doing this. As for "best", I'd lean towards BeOS (as it's streamlined for this kind of thing), but "whichever one has both this software and the other day-to-day software you use" is probably the best answer, IMO.
The problem is that you have to provide a convincing argument that the company will make more money from the product if it is open-sourced than they would if it was closed-source.
This will be easier if:
The product isn't doing well. If the product isn't pulling in much revenue, open sourcing it won't drop revenue by *that* much, and you may have a revitalized market for related products if the open sourced version of the product takes off.
You are already making most of your money off of service contracts. If support is where most of the money is made from the product, then open sourcing the product means more demand for support and more revenue.
You are making money off of hardware that the product runs on. If hardware is where most of the money is made from the product, then open sourcing the software will encourage more software to be produced for the platform, driving up demand for the hardware and revenue.
You have a hopeless task if:
The money is made by selling the software, and it's selling well. Under these conditions, there is no benefit at all financially to making the product open source, as a very substantial revenue stream will vanish in a puff of smoke.
Any benefit provided by open sourcing has to outweigh the following automatic drawbacks:
Loss of direct revenue from selling the software. You may be able to sell CDs, you may not, but whatever you do, you won't be able to charge hundreds or thousands of dollars per software license any more. Direct revenue drops like a stone.
Giving free R&D benefits to the competition. Software does not exist in a vacuum. While your competitors could reverse-engineer how all of your features work by disassembly or by keen observation, it will be much easier if you hand out sample code for them. Your company will have to work a lot harder to maintain a technical advantage over its competition, and any such advantages will be short-lived. This worsens your product's position with respect to your competition and thus lowers your sales.
Also, in case you were planning to tout the benefits of opening up the Linux market, bear in mind that that market is still very small compared to the Windows market. Ditto BSD and MacOS X (though the MacOS X market isn't *that* small).
Both open source and free software are wonderful ideas, useful for a great many things - but they are not a magic wand that benefits everything. Your company might be substantially _harmed_ by switching over. Make sure of the benefits of your proposal before pitching.
Not to imply Intel had rigged this one, but a single demo of a single P4@2GHz doesn't mean we'll that chip at that speed for sale any time soon.
One easy way in which Intel could have boosted performance numbers: Fab a P4 at 0.13 microns.
0.13 micron fabbing in quantity won't be around for a while, but IBM will, for a price, give you small runs on their X-ray lithography rig at 0.12 and below (as of years ago; it may be even finer now).
Intel may also have an experimental 0.13 fab line for fine-tuning processes before launch. 0.13 should be available in quantity around Christmas or so if I'm getting Moore's law right.
With either of these approaches, Intel would have to do custom tweaking of design parameters for the target process, but it might be worth the effort if it provides a 2 GHz demo chip.
Or, their uber-pipelined chip really _may_ run that fast in an aggressive cooling rig. See elsewhere for the short/long pipeline debate.
I am tired of seeing Intel put out more and more vaporware. RDRAM, IA-64, etc, etc..
You can buy RDRAM right now if you want to. Hardly vapour.
Engineering prototypes of the IA-64 have been around for a while, with every indication that they will ship. Doesn't look very vaprous to me.
IA-64 has 1/5 the performance of an alpha under gcc, which is not optimised for the alpha. (likely the kind that is 3x an Athlon or more for a P3)
Firstly, GCC is not the best compiler in the world. When comparing an Alpha to an IA-64 chip, I'd use Intel's compiler on the IA-64 and Compaq's compiler on the Alpha. Both companies have a history of writing compilers that were extremely well optimized for their platforms.
Secondly, I don't see much support for your figures. See my next point.
Even a 2 year old alpha can beat most P3s (1.5 -2x P3 MHz = alpha MHz in performance)
Not really. Alpha chips are about even in everything except floating point (where the Alpha blows *everyone* out of the water - Sun, HP, IBM, Motorola, etc).
They do this with the higher speed grades of their chips that were released _recently_. Older chips used the same design but were clocked more slowly, and don't blow away present chips.
Check http://www.spec.org for reasonably accurate benchmark information. They use the fairest system for evaluation that I've seen (standard test code supplied by SPEC, compilation and system tweaking handled by the companies owning the platforms being tested).
As far as the performance of the Alpha or an Athlon vs. the P4 goes... The P4 is still in the final debugging stages. Wait six months and look for SPEC marks.
Personally, I'd like to see SPEC marks for the G4. Apple has been allergic to SPEC of late.
Because it's made by Nintendo. Ever since the SuperNintendo, Nintendo has been release under-powered, under-featured consoles that nevertheless sell like crazy.
...
Had Nintendo beefed up the hardware for the SNES and N64, you might not even be hearing about Dreamcast, PS2 or XBox.
I question these comparisons, as the N64 was released _years_ earlier than the systems you list above.
In my experience, Nintendo has usually waited six months to a year after Sega released a platform and then released a platform with superior hardware that blew them out of the water.
Rememeber the Sega Genesis? It made the NES look very shabby, until Nintendo rolled out the Super NES as *their* entry into the 16-bit arena.
The N-64 was Nintendo's first-generation 3D console, designed to compete with the Playstation (Sony's first-generation 3D console) and Sega's Saturn.
Now we're seeing Nintendo's next-generation 3D console, designed to blow away the Dreamcast and the Playstation 2 - and it just might do it. 16 megs of _embedded_ _SRAM_ means no memory bottlenecks in the graphics subsystem, and T&L at 0.18 copper (migrating to 0.13) should take care of geometry.
Again, it looks like Nintendo is releasing _superior_ hardware about 6-12 months after the competition.
Nintendo's achilles heel has always been game quality, as opposed to platform capability. There are good games for Nintendo machines, but there are also many mediocre ones, and my gaming-nut friends tell me that the signal to noise ratio is substantially better with other platforms.
I understand that nudging the duty-cycle would cause spreading in the frequency domain (at least, I think I do) but didn't the article say that the signal is then run through some narrow bandpass filters or something? So then wouldn't the nudging sort of degrade to a phase shift or something?
My point was that this filtering would lose information. Your available bandwidth influences how fine and how fast a phase shift you can detect.
You can think of VMSK/2 as a form of duty-cycle modulation (Figure 1). Think of a "square" wave whose total period does not vary but which, depending on whether a given bit interval contains a 1 or a 0, spends slightly more or slightly less than half the period in the high state.
Problem - this kind of nudging of the duty cycle causes spreading in the frequency domain. In fact, it is these additional frequencies that encode the change in the duty cycle.
If you try to transmit a signal modulated using this technique through a very narrow channel centered about the carrier frequency, you will lose a lot of the duty cycle information, and your data signal will degrade a *lot*.
I am skeptical of this getting much more effective use of bandwidth than conventional encoding schemes. The best I can see them getting is a modest gain if this technique is less sensitive to common types of noise (which has yet to be demonstrated).
The same page contains benchmarks against other popular databases as well.
NOTE: Pay attention to the numbers, as well as the bar diagrams. The bars are all clipped at the right side of the chart, which is misleading for a few rows.
There are also penalties -- for example, the page table hierarchy has 4 levels, which means more memory accesses on a TLB miss.
While this is true, its impact can be reduced by having a multi-level TLB (cache the physical addresses for lower level pages of the page table as well as the physical addresses for the destination page). Several architectures already do this.
This would allow me to get a new page's physical address with a single lookup, as long as it's within the same block of pages as another page I've already accessed.
Here's a warped thought - set up a CVS server with all config files and applications that you care about updating checked in.
Set up a cron job on each machine to check out the latest version of the installation every day at 5am. Make the cron job shut down and reinitialize anything important, too (or just have it reboot the machine and let init/shutdown scripts take care of it).
This isn't a remote admin solution, but it _does_ let you easily make sure that all packages and config files on the machines are in synch. Upgrade Netscape on the master server, for instance, and the other installations migrate over in a few hours.
You could even rig it so that the cron job calls a specific script before completion, and check that script out of CVS for any specific shell-ish things that have to be done for maintenance to complete the update (test these scripts carefully, though).
Caveat: A pH of 4.4 is a worst-case estimate, as other dissolved substances in the bloodstream will make the CO2 less soluble (witness the effect of dropping salt into a can of Coke).
That's not what they told us.
I'll look up my course notes.
I did question them, but they were adamant about it being toxic. They couldn't tell me why though.
I've done a web search, and most of the information I've found just mentions toxicity due to displacement of oxygen from the atmosphere, as per my original post. The limits that are specified are either very high when reporting actual test results (in the 50% v/v range to kill rats), or are in the low-percentile range and explicitly stated to just be the highest limit allowed by the classification schemes used.
One reference mentioned acidification of the blood as an effect of high CO2 concentration, but only to mention that it wasn't significant in the few-percent range. It would probably be relevant at high pressure (e.g. for divers), but I'm not sure if it's a concern at STP.
Hmm.
Solubility of CO2 in water, according to Ye Rubber Bible, is just under 0.1 g/L, for about 0.002 moles/L. Water has a "concentration" of about 56 moles/L. This gives a relative concentration in water of about 3.6e-5 M/M, for a pH of 4.4 assuming 100% dissociation.
What is the minimum safe pH of blood?
Re:Use for multitaasking, multiuser, networked box
on
A Praise To Unix
·
· Score: 2
Why do you need a multi-user machine at each desk in an organization, and in each bedroom in a large family's house?
The machines in the _living_room_ must be multi-user, because I don't want to trek down to my room downstairs to access my files if I'm in the living room.
Even if you assume that only one person will ever need a machine, they still have to understand the concept of multiple users - otherwise they won't be able to talk to the file server. Do I want to have to use floppy disks if I want to share files with my other family members?
Why must each person be _bound_ to one machine? If anything, _that's_ a waste of hardware, as it requires one machine per person (you will note that I said my parents share a machine). If I have an extra $1k to spare, I'll add a mail server or upgrade the RAID or replace our aging laser printer, not add a new user terminal.
I have a feeling I've been trolled here, but what the heck.
What happens if somehow it malfunctions and you get deadly carbon dioxide released into your room.
Carbon dioxide is not toxic.
The only possible dangerous scenario would be filling the entire room with CO2, in which case you'd suffocate (no oxygen). However, with any ventilation at _all_ this can't happen.
Caveat: Don't fill a basement with CO2. It's heavier than air, and will just sit there. If you start feeling drowsy after a minute or so, get out.
Lastly, they had a total of 4 kg of CO2. Gaseous CO2 at room temperature has a density of about 1.7 kg per cubic metre. Even if *all* of the CO2 vapourized *and* they were in a basement and had no ventilation, the suffocating pool of CO2 would come up to about their ankles.
In summary - No danger.
Use for multitaasking, multiuser, networked boxes.
on
A Praise To Unix
·
· Score: 2
So, do most people need multiuser, multitasking, networked operating systems? No.
In the days when there was one computer in the house and it was used by one person, this was true. However, it is becoming less and less the case.
If I have a computer, my brother has a computer, and my parents share a computer, I definitely need networking if I want to be able to do anything useful if I sit down at any machine other than my own.
I also don't want to deal with synching my home directories on several different machines, which means having one dedicated system for storage.
As I don't want my brother rearranging my home directory and I don't want my directory stomped if Windows crashes badly on one of the other machines, I need to have some concept of user-based permissions to protect my directories from others' mistakes... which means multi-user support.
As I've had a few drives die on me over the years, and as I don't want to keep my own machine on all of the time, it's prudent to put user home directories on a dedicated fileserver with a software RAID...
...and so forth.
Whenever you have more than one machine and more than one user in a house, you have something that looks less like the old "one person, one PC" model and more like a university computer lab - complete with multiuser support and networked services.
So, I would indeed argue that these aspects of OS design are becoming more important for Joe Average user.
Even as I type, I am dl'ing the source packages to do the same thing. I tried (in vain) to install RH on a Thinkpad 360P. No matter what I did, I could not get rid of enough packages to fit on a 250 +/- partition. Too damned many interdependencies. As I don't have a current disk for a conventional distro, I figured I'd do it this way.
You might want to try Slackware for your notebook. Depending on what you leave out, you should be able to get it down to 250 megs without too much difficulty (just don't plan on rebuilding X from source, for instance). I've had to install it on limited space myself a few times.
And if you feel like mixing and matching pieces, all of it's stored as straight tarballs on the CD, so it's easy to pick through (though I'm sure tools for RPM and DEB let you do this too).
Most computers use switched-mode power supplies. These are a mainly INDUCTIVE load on the grid.
Um, don't most computer power supplies contain a large capacitor to even out the power factor? Your power company would be Unhappy if you decided to plug a substantial inductive load into your wall socket.
Even if the computers themselves overlook this, a co-lo facility wouldn't. IIRC you're billed substantially above the standard rate for your power if you have an inductive load. This is why most industrial machinery takes care to add enough capacitance to get a power factor near unity. A co-lo facility would add this to its server racks if the power supplies themselves didn't handle it, to minimize hassle from the power company.
All in all, how much longer do people think before we get to some barrier to further advances...
From one point of view, we already are at the barrier. We have telescopes that can resolve images at the theoretical resolution limit for their aperture size (as governed by diffraction), we have telescopes that can focus all or almost all of the light falling on their (filled) apertures on to their detectors, and we have detectors that can detect individual photons. In other words, our telescopes are approaching the best possible efficiency for whatever aperture size we choose to build.
From another point of view, we will have the potential for continued advancement for quite a while to come. Optical interferometry-based telescopes are just starting to come into their own, which will allow us to build telescopes with synthetic apertures arbitrarily long. Segmented mirror technology continues to improve, with the maximum size of segmented mirror systems growing incrementally larger. Space-based telescopes are still an immature technology; while space-based telescopes won't be more efficient per se than ground-based telescopes, they can view wavelength ranges that the atmosphere blocks. There is also a fair bit of work to be done on automated instrumentation (as of the last few articles I've read on the subject, galaxy spectra surveys are still slow and involve a lot of fiddling, for example).
In summary, while we're starting to approach perfect efficiency for the telescopes we've built, there is still a lot of engineering to be done in order to incrementally broaden the range of telescopes that _can_ be built.
Of particular interest in the article are the safeguards against the common opposition to such projects, like their use for piracy. Publius features no search utility and a maximum file size of 100k.
An admirable effort, but this just means that someone will circulate a third-party utility that does indexing and can reassemble fragmented files from 100k packets.
Still, it should cut down on the number of people storing CD images.
My intent here was to have two 10G disks instead of one 20G disk, and partition them in a way so that if one disk failed, I could keep running essential stuff (like news, mail and the web server) on one until I could buy another. That's why each partition on/dev/hda has a corresponding partition of the same size on/dev/hdc. I have a nightly script that copies [...]
I have a similar philosophy, but just used mdtools to set things up as a RAID1 across two 13 gig drives. Everything but the root partition is on the RAID, and I made a manual copy of the root partition on the second drive. If the secondary drive dies, no problem. If the primary drive dies, I use a floppy to boot off of the secondary drive's root partition, and again no problem.
I haven't been brave enough to yank a drive to test this. I also suspect that my recovery skills aren't up to snuff; however, mdtools leaves a valid ext2 filesystem on each of the partitions, so in the worst case I can mount the valid drive's partitions as ext2 and spend several hours shuffling files to another drive, wiping the RAID drives, and reconfiguring the RAID.
As for that, I think your analysis of the possibility of stable orbits is naive. Your conclusion might be right, but your method isn't valid. Whether an orbit in a many-body system are stable over millions of cycles is not trivial to calculate, and the effects of a perturbing force like a large planet do not just scale linearly with the force of its gravity.
You can most certainly resolve this with "back-of-the-envelope" calculations.
It is only the _relative_ masses and positions of the objects that matter. Absolute scale is irrelevant - it just imposes a scaling factor on time. This means that I can make valid conclusions by comparing the Eridani system to the Sol system.
The only variable in the Eridani system that differs from the Sol system is the relative masses of the star and the gas giant planet, and this doesn't change much - Epsilon Eridani is about 0.75 solar masses, according to a quick web search.
Thus, I would be very surprised if my conclusion _didn't_ hold.
We're talking about a gas giant close enough and big enought to make the star wobble noticably. That's a very rough gravitational environment for a small planet to find a stable orbit in.
The key word is "noticeably".
We've had spectrographs for many, many decades, and *only* *now* have instruments sensitive enough to detect the extremely slight perturbation of spectral lines due to planetary nudging of parent stars.
The effects of a gas giant planet are not as severe as you make them out to be.
Slashdot Mirror
If you're worried about a leak damaging your computer, you could always use vegetable oil as your coolant. Heat capacity isn't as good, and you'll have to take off the heat sink assembly and flush it with soapy water every few months, but it's better than air and won't damage electronics if there is a leak.
Many other possible coolants exist; just bear in mind that you don't want your coolant to be very flammable (so something like kerosene is not an option, despite lower viscosity).
In case anyone else is as bored as I was, here are the calculations and the numbers:
- Assume, arbitrarily, that your device is made of carbon and has one computing element (gate or memory element) per 10 atoms, average. This gives a total of about (1000 / (12 * 10)) * 6e23 = 5e24 computing elements.
- Assume that we're going for floating-point performance, and are using most of our elements for multiplication units. Assume we're cheating and using single-precision ints (32 bits). If we're allowed to pipeline arbitrarily deeply (we're runnign a toy benchmark program), then it would take somewhere in the realm of 4000 computing elements to build an IEEE-compliant floating point multiplier. This gives us 5e24/4000 = 1.25e21 multiplication units operating in parallel.
- Assume that we're signalling using light and that the light has to travel 1 nm per clock (we're very good at routing traces). This gives a clock frequency of 3e8/1e-9 = 3e17 Hz.
- This gives us a total of 1.25e21 x 3e17 = 3.75e38 FLOPS. Less than the best, but still not too shabby.
For kicks, let's compute the power requirements of this device.
- Assume that on every clock, half of the computation units change state (we're managing to use all of the computation units all of the time, with random data). This gives 5e24 / 2 = 2.5e24 transitions per clock.
- This gives 2.5e24 * 3e17 = 7.5e41 transitions per second.
- Assume that each transiton costs about 5 eV in total (split this however you like). This gives 5 eV * 1.6e-19 J/eV = 8e-19 Joules per transition.
- This gives us a power dissipation of 6e23 watts. A bit power-hungry.
For kicks, let's compute the surface temperature of this computer assuming radiative cooling:
- Assume that our computer is a 10-cm cube, with a density comparable to that of water (this is strangely-structured carbon). This gives us a surface area of 6e-2 square metres.
- Radiative energy emission from the object will therefore be equal to 6e-2 * 5.67e-8 * T^4 = 3.46e-9 * T^4 watts, where T is the object's surface temperature.
- For a power dissipation of 6e23 watts, the object's surface temperture would be (6e23 / 3.46e-9) ^ (1/4) = 1.15e8 degrees Kelvin. A bit warm.
Summary of data for the best possible nanotech computer:
Looks like we'd have to underclock this baby.
Derivation of computing power for a comparably-sized quantum computer is left as an exercise for the reader.
In practice, we'd probably wind up building our nanocomputers as thin films with a lot less computing power but far lower power dissipation. Possibly as nano-grains, also, depending on application.
If your company is liable for any email originating from it, then a logical solution is to block outgoing email from most users. Give the company a few official contact people who talk to clients directly, and act as go-betweens for other work-related email.
Non-work-related email can be handled through home accounts, POP3 to an employee's ISP's mail server, web mail, or what-have-you.
This is draconian, but it does virtually eliminate the problem of liability for outgoing email. Internal email management is left as an exercise to the reader.
I can rattle off lots of processors that are more efficient than x86 (RISC processors such as PA-RISC, MIPS, SPARC, DEC Alpha ARM, etc.)
Most of these processors aren't appropriate for a gaming platform.
PA-RISC, SPARC, and Alpha chips are workstation-class and priced accordingly. They'd cost at least as much as the retail price of your console - not something you can use.
ARM chips have horrible FP performance (the older versions didn't even have an FPU). This is a deliberate design trade-off; having only integer operations lets you save a lot of silicon and a lot of power. But gaming consoles need floating-point big time for physics, 3D collision detection, and any transformations that aren't handled by the hardware (there will be many). So this too is not something you can use.
MIPS chips would be an acceptable choice - if you license the core and fab your own chips. But this is expensive, and leads to more effort required in the motherboard design as well. You can do this if you're a console company and are optimized for it - but Microsoft isn't on either count.
So Intel looks like the best choice for Microsoft just from a price and design effort point of view.
remember NT came out originally for MIPS, Intel and Alpha. Mips and Alpha are long gone
And this is another *VERY* big reason for Microsoft to use Intel chips - they don't need to rewrite their operating system from scratch for a new platform. That would take a horrific amount of work, especially since they're porting DirectX as well as the OS itself.
A gaming console must do one thing and it must do it well, which screams RISC to me
Modern CISC-ish processors are just as efficient. Instruction decoding is a little hairier, but that's pretty much a solved problem. This is the old "CISC decoder with a RISC core" description that you've been hearing for both Intel and AMD chips (not precisely accurate, but close enough).
The big flaw in Intel chips is that it has few general-purpose registers, but so far the chips have held up without a vast performance gap.
I've read the article over at Ars on the Emotion Engine and it looks like if software developers can get their heads around it, the Playstation 2 should lay waste to the Xbox.
The Playstation 2 is nice, but still have a few serious design flaws. The fact that it has only a miniscule amount of frame buffer memory is the most obvious of these, but I'm a bit skeptical of the bus as well.
Realistic performance figures that I've heard for the Playstation put the X-box ahead (not surprising, as it has a graphics chip that's a couple of generations later than the Playstation, due to a later release date).
Software optimization *should* be a solved problem if Sony writes or has written, say, an OpenGL implementation optimized for their hardware.
I'm not a big fan of the X-box, but I'm afraid that I disagree with several of the points you use in your argument against it.
Which would make a better OS for a software synthesizer:
The simple answer: Whichever platform has the software already existing for it (at least if you need to use it in the near future).
The ideal situation would seem to be an OS that has the graphical capability to present an interface for MAKING instruments, and then a working capability where the graphics are gone and you PLAY the instruments. Whizbang stuff for building the instruments, and simple multitimbral interface for using the built instruments.
All of the OSes you listed are _capable_ of doing this. As for "best", I'd lean towards BeOS (as it's streamlined for this kind of thing), but "whichever one has both this software and the other day-to-day software you use" is probably the best answer, IMO.
This will be easier if:
If the product isn't pulling in much revenue, open sourcing it won't drop revenue by *that* much, and you may have a revitalized market for related products if the open sourced version of the product takes off.
If support is where most of the money is made from the product, then open sourcing the product means more demand for support and more revenue.
If hardware is where most of the money is made from the product, then open sourcing the software will encourage more software to be produced for the platform, driving up demand for the hardware and revenue.
You have a hopeless task if:
Under these conditions, there is no benefit at all financially to making the product open source, as a very substantial revenue stream will vanish in a puff of smoke.
Any benefit provided by open sourcing has to outweigh the following automatic drawbacks:
You may be able to sell CDs, you may not, but whatever you do, you won't be able to charge hundreds or thousands of dollars per software license any more. Direct revenue drops like a stone.
Software does not exist in a vacuum. While your competitors could reverse-engineer how all of your features work by disassembly or by keen observation, it will be much easier if you hand out sample code for them. Your company will have to work a lot harder to maintain a technical advantage over its competition, and any such advantages will be short-lived. This worsens your product's position with respect to your competition and thus lowers your sales.
Also, in case you were planning to tout the benefits of opening up the Linux market, bear in mind that that market is still very small compared to the Windows market. Ditto BSD and MacOS X (though the MacOS X market isn't *that* small).
Both open source and free software are wonderful ideas, useful for a great many things - but they are not a magic wand that benefits everything. Your company might be substantially _harmed_ by switching over. Make sure of the benefits of your proposal before pitching.
Not to imply Intel had rigged this one, but a single demo of a single P4@2GHz doesn't mean we'll that chip at that speed for sale any time soon.
One easy way in which Intel could have boosted performance numbers: Fab a P4 at 0.13 microns.
0.13 micron fabbing in quantity won't be around for a while, but IBM will, for a price, give you small runs on their X-ray lithography rig at 0.12 and below (as of years ago; it may be even finer now).
Intel may also have an experimental 0.13 fab line for fine-tuning processes before launch. 0.13 should be available in quantity around Christmas or so if I'm getting Moore's law right.
With either of these approaches, Intel would have to do custom tweaking of design parameters for the target process, but it might be worth the effort if it provides a 2 GHz demo chip.
Or, their uber-pipelined chip really _may_ run that fast in an aggressive cooling rig. See elsewhere for the short/long pipeline debate.
I am tired of seeing Intel put out more and more vaporware. RDRAM, IA-64, etc, etc..
You can buy RDRAM right now if you want to. Hardly vapour.
Engineering prototypes of the IA-64 have been around for a while, with every indication that they will ship. Doesn't look very vaprous to me.
IA-64 has 1/5 the performance of an alpha under gcc, which is not optimised for the alpha. (likely the kind that is 3x an Athlon or more for a P3)
Firstly, GCC is not the best compiler in the world. When comparing an Alpha to an IA-64 chip, I'd use Intel's compiler on the IA-64 and Compaq's compiler on the Alpha. Both companies have a history of writing compilers that were extremely well optimized for their platforms.
Secondly, I don't see much support for your figures. See my next point.
Even a 2 year old alpha can beat most P3s (1.5 -2x P3 MHz = alpha MHz in performance)
Not really. Alpha chips are about even in everything except floating point (where the Alpha blows *everyone* out of the water - Sun, HP, IBM, Motorola, etc).
They do this with the higher speed grades of their chips that were released _recently_. Older chips used the same design but were clocked more slowly, and don't blow away present chips.
Check http://www.spec.org for reasonably accurate benchmark information. They use the fairest system for evaluation that I've seen (standard test code supplied by SPEC, compilation and system tweaking handled by the companies owning the platforms being tested).
As far as the performance of the Alpha or an Athlon vs. the P4 goes... The P4 is still in the final debugging stages. Wait six months and look for SPEC marks.
Personally, I'd like to see SPEC marks for the G4. Apple has been allergic to SPEC of late.
Because it's made by Nintendo. Ever since the SuperNintendo, Nintendo has been release under-powered, under-featured consoles that nevertheless sell like crazy.
...
Had Nintendo beefed up the hardware for the SNES and N64, you might not even be hearing about Dreamcast, PS2 or XBox.
I question these comparisons, as the N64 was released _years_ earlier than the systems you list above.
In my experience, Nintendo has usually waited six months to a year after Sega released a platform and then released a platform with superior hardware that blew them out of the water.
Rememeber the Sega Genesis? It made the NES look very shabby, until Nintendo rolled out the Super NES as *their* entry into the 16-bit arena.
The N-64 was Nintendo's first-generation 3D console, designed to compete with the Playstation (Sony's first-generation 3D console) and Sega's Saturn.
Now we're seeing Nintendo's next-generation 3D console, designed to blow away the Dreamcast and the Playstation 2 - and it just might do it. 16 megs of _embedded_ _SRAM_ means no memory bottlenecks in the graphics subsystem, and T&L at 0.18 copper (migrating to 0.13) should take care of geometry.
Again, it looks like Nintendo is releasing _superior_ hardware about 6-12 months after the competition.
Nintendo's achilles heel has always been game quality, as opposed to platform capability. There are good games for Nintendo machines, but there are also many mediocre ones, and my gaming-nut friends tell me that the signal to noise ratio is substantially better with other platforms.
I understand that nudging the duty-cycle would cause spreading in the frequency domain (at least, I think I do) but didn't the article say that the signal is then run through some narrow bandpass filters or something? So then wouldn't the nudging sort of degrade to a phase shift or something?
My point was that this filtering would lose information. Your available bandwidth influences how fine and how fast a phase shift you can detect.
Good question, though.
From the article:
You can think of VMSK/2 as a form of duty-cycle modulation (Figure 1). Think of a "square" wave whose total period does not vary but which, depending on whether a given bit interval contains a 1 or a 0, spends slightly more or slightly less than half the period in the high state.
Problem - this kind of nudging of the duty cycle causes spreading in the frequency domain. In fact, it is these additional frequencies that encode the change in the duty cycle.
If you try to transmit a signal modulated using this technique through a very narrow channel centered about the carrier frequency, you will lose a lot of the duty cycle information, and your data signal will degrade a *lot*.
I am skeptical of this getting much more effective use of bandwidth than conventional encoding schemes. The best I can see them getting is a modest gain if this technique is less sensitive to common types of noise (which has yet to be demonstrated).
Following the links from the page with the article, I find MySQL's site with their own benchmarks of MySQL vs. Postgres: http://www.mysql.com/information/benchmarks.html .
The same page contains benchmarks against other popular databases as well.
NOTE: Pay attention to the numbers, as well as the bar diagrams. The bars are all clipped at the right side of the chart, which is misleading for a few rows.
There are also penalties -- for example, the page table hierarchy has 4 levels, which means more memory accesses on a TLB miss.
While this is true, its impact can be reduced by having a multi-level TLB (cache the physical addresses for lower level pages of the page table as well as the physical addresses for the destination page). Several architectures already do this.
This would allow me to get a new page's physical address with a single lookup, as long as it's within the same block of pages as another page I've already accessed.
Here's a warped thought - set up a CVS server with all config files and applications that you care about updating checked in.
Set up a cron job on each machine to check out the latest version of the installation every day at 5am. Make the cron job shut down and reinitialize anything important, too (or just have it reboot the machine and let init/shutdown scripts take care of it).
This isn't a remote admin solution, but it _does_ let you easily make sure that all packages and config files on the machines are in synch. Upgrade Netscape on the master server, for instance, and the other installations migrate over in a few hours.
You could even rig it so that the cron job calls a specific script before completion, and check that script out of CVS for any specific shell-ish things that have to be done for maintenance to complete the update (test these scripts carefully, though).
Caveat: A pH of 4.4 is a worst-case estimate, as other dissolved substances in the bloodstream will make the CO2 less soluble (witness the effect of dropping salt into a can of Coke).
That's not what they told us.
I'll look up my course notes.
I did question them, but they were adamant about it being toxic. They couldn't tell me why though.
I've done a web search, and most of the information I've found just mentions toxicity due to displacement of oxygen from the atmosphere, as per my original post. The limits that are specified are either very high when reporting actual test results (in the 50% v/v range to kill rats), or are in the low-percentile range and explicitly stated to just be the highest limit allowed by the classification schemes used.
One reference mentioned acidification of the blood as an effect of high CO2 concentration, but only to mention that it wasn't significant in the few-percent range. It would probably be relevant at high pressure (e.g. for divers), but I'm not sure if it's a concern at STP.
Hmm.
Solubility of CO2 in water, according to Ye Rubber Bible, is just under 0.1 g/L, for about 0.002 moles/L. Water has a "concentration" of about 56 moles/L. This gives a relative concentration in water of about 3.6e-5 M/M, for a pH of 4.4 assuming 100% dissociation.
What is the minimum safe pH of blood?
Why do you need a multi-user machine at each desk in an organization, and in each bedroom in a large family's house?
The machines in the _living_room_ must be multi-user, because I don't want to trek down to my room downstairs to access my files if I'm in the living room.
Even if you assume that only one person will ever need a machine, they still have to understand the concept of multiple users - otherwise they won't be able to talk to the file server. Do I want to have to use floppy disks if I want to share files with my other family members?
Why must each person be _bound_ to one machine? If anything, _that's_ a waste of hardware, as it requires one machine per person (you will note that I said my parents share a machine). If I have an extra $1k to spare, I'll add a mail server or upgrade the RAID or replace our aging laser printer, not add a new user terminal.
I have a feeling I've been trolled here, but what the heck.
What happens if somehow it malfunctions and you get deadly carbon dioxide released into your room.
Carbon dioxide is not toxic.
The only possible dangerous scenario would be filling the entire room with CO2, in which case you'd suffocate (no oxygen). However, with any ventilation at _all_ this can't happen.
Caveat: Don't fill a basement with CO2. It's heavier than air, and will just sit there. If you start feeling drowsy after a minute or so, get out.
Lastly, they had a total of 4 kg of CO2. Gaseous CO2 at room temperature has a density of about 1.7 kg per cubic metre. Even if *all* of the CO2 vapourized *and* they were in a basement and had no ventilation, the suffocating pool of CO2 would come up to about their ankles.
In summary - No danger.
So, do most people need multiuser, multitasking, networked operating systems? No.
In the days when there was one computer in the house and it was used by one person, this was true. However, it is becoming less and less the case.
If I have a computer, my brother has a computer, and my parents share a computer, I definitely need networking if I want to be able to do anything useful if I sit down at any machine other than my own.
I also don't want to deal with synching my home directories on several different machines, which means having one dedicated system for storage.
As I don't want my brother rearranging my home directory and I don't want my directory stomped if Windows crashes badly on one of the other machines, I need to have some concept of user-based permissions to protect my directories from others' mistakes... which means multi-user support.
As I've had a few drives die on me over the years, and as I don't want to keep my own machine on all of the time, it's prudent to put user home directories on a dedicated fileserver with a software RAID...
...and so forth.
Whenever you have more than one machine and more than one user in a house, you have something that looks less like the old "one person, one PC" model and more like a university computer lab - complete with multiuser support and networked services.
So, I would indeed argue that these aspects of OS design are becoming more important for Joe Average user.
Even as I type, I am dl'ing the source packages to do the same thing. I tried (in vain) to install RH on a Thinkpad 360P. No matter what I did, I could not get rid of enough packages to fit on a 250 +/- partition. Too damned many interdependencies. As I don't have a current disk for a conventional distro, I figured I'd do it this way.
You might want to try Slackware for your notebook. Depending on what you leave out, you should be able to get it down to 250 megs without too much difficulty (just don't plan on rebuilding X from source, for instance). I've had to install it on limited space myself a few times.
And if you feel like mixing and matching pieces, all of it's stored as straight tarballs on the CD, so it's easy to pick through (though I'm sure tools for RPM and DEB let you do this too).
Most computers use switched-mode power supplies. These are a mainly INDUCTIVE load on the grid.
Um, don't most computer power supplies contain a large capacitor to even out the power factor? Your power company would be Unhappy if you decided to plug a substantial inductive load into your wall socket.
Even if the computers themselves overlook this, a co-lo facility wouldn't. IIRC you're billed substantially above the standard rate for your power if you have an inductive load. This is why most industrial machinery takes care to add enough capacitance to get a power factor near unity. A co-lo facility would add this to its server racks if the power supplies themselves didn't handle it, to minimize hassle from the power company.
All in all, how much longer do people think before we get to some barrier to further advances...
From one point of view, we already are at the barrier. We have telescopes that can resolve images at the theoretical resolution limit for their aperture size (as governed by diffraction), we have telescopes that can focus all or almost all of the light falling on their (filled) apertures on to their detectors, and we have detectors that can detect individual photons. In other words, our telescopes are approaching the best possible efficiency for whatever aperture size we choose to build.
From another point of view, we will have the potential for continued advancement for quite a while to come. Optical interferometry-based telescopes are just starting to come into their own, which will allow us to build telescopes with synthetic apertures arbitrarily long. Segmented mirror technology continues to improve, with the maximum size of segmented mirror systems growing incrementally larger. Space-based telescopes are still an immature technology; while space-based telescopes won't be more efficient per se than ground-based telescopes, they can view wavelength ranges that the atmosphere blocks. There is also a fair bit of work to be done on automated instrumentation (as of the last few articles I've read on the subject, galaxy spectra surveys are still slow and involve a lot of fiddling, for example).
In summary, while we're starting to approach perfect efficiency for the telescopes we've built, there is still a lot of engineering to be done in order to incrementally broaden the range of telescopes that _can_ be built.
Of particular interest in the article are the safeguards against the common opposition to such projects, like their use for piracy. Publius features no search utility and a maximum file size of 100k.
An admirable effort, but this just means that someone will circulate a third-party utility that does indexing and can reassemble fragmented files from 100k packets.
Still, it should cut down on the number of people storing CD images.
My intent here was to have two 10G disks instead of one 20G disk, and partition them in a way so that if one disk failed, I could keep running essential stuff (like news, mail and the web server) on one until I could buy another. That's why each partition on /dev/hda has a corresponding partition of the same size on /dev/hdc. I have a nightly script that copies [...]
I have a similar philosophy, but just used mdtools to set things up as a RAID1 across two 13 gig drives. Everything but the root partition is on the RAID, and I made a manual copy of the root partition on the second drive. If the secondary drive dies, no problem. If the primary drive dies, I use a floppy to boot off of the secondary drive's root partition, and again no problem.
I haven't been brave enough to yank a drive to test this. I also suspect that my recovery skills aren't up to snuff; however, mdtools leaves a valid ext2 filesystem on each of the partitions, so in the worst case I can mount the valid drive's partitions as ext2 and spend several hours shuffling files to another drive, wiping the RAID drives, and reconfiguring the RAID.
As for that, I think your analysis of the possibility of stable orbits is naive. Your conclusion might be right, but your method isn't valid. Whether an orbit in a many-body system are stable over millions of cycles is not trivial to calculate, and the effects of a perturbing force like a large planet do not just scale linearly with the force of its gravity.
You can most certainly resolve this with "back-of-the-envelope" calculations.
It is only the _relative_ masses and positions of the objects that matter. Absolute scale is irrelevant - it just imposes a scaling factor on time. This means that I can make valid conclusions by comparing the Eridani system to the Sol system.
The only variable in the Eridani system that differs from the Sol system is the relative masses of the star and the gas giant planet, and this doesn't change much - Epsilon Eridani is about 0.75 solar masses, according to a quick web search.
Thus, I would be very surprised if my conclusion _didn't_ hold.
We're talking about a gas giant close enough and big enought to make the star wobble noticably. That's a very rough gravitational environment for a small planet to find a stable orbit in.
The key word is "noticeably".
We've had spectrographs for many, many decades, and *only* *now* have instruments sensitive enough to detect the extremely slight perturbation of spectral lines due to planetary nudging of parent stars.
The effects of a gas giant planet are not as severe as you make them out to be.