NRAM, currently in commercial production, uses nanotubes to store data. From the manufacturer's site:
NRAM will be considerably faster and denser than DRAM, have substantially lower power consumption than DRAM or flash, be as portable as flash memory, and be highly resistant to environmental forces (heat, cold, magnetism). And as a nonvolatile chip, it will provide permanent data storage even without power. Possible uses include the enabling of instant-on computers, which boot and reboot instantly, as well as high-density portable memory - MP3 players with 1000s of songs, PDAs with 10 gigabytes of memory, high-speed network servers and much more.
The proprietary NRAM design, invented by Dr. Thomas Rueckes, Nantero's Chief Scientific Officer, uses carbon nanotubes as the active memory elements. Carbon nanotubes are members of the fullerene family and have amazing properties, including the ability to conduct electricity as well as copper while being stronger than steel and as hard as diamond. The wall of a single-walled carbon nanotube is only one carbon atom thick and the tube diameter is approximately 100,000 times smaller than a human hair. Dr. Rueckes' pioneering design takes advantage of these unique properties while cleverly integrating nanotubes with traditional semiconductor technologies for immediate manufacturability.
Good question, especially considering FreeBSD Tinderbox has been doing this sort of thing for years, and not just with the kernel but with the entire base system.
Building a supercomputer that runs vaporware seems like a rather foolhardy exercise indeed.
GenoByte has found a more novel use for FPGAs, which they call "evolvable hardware." Much like our own brains neural networks on the FPGAs reconfigure the way they interconnect on the fly; commonly used paths are reenforced while less frequently used ones atrophy.
All in all this approach is substantially faster than modelling large neural networks on a general purpose processor. In the GenoByte approach, the neural network is implemented as physical circuits.
Let's not forget that even if these researchers are wrong and such a wormhole would be stable, opening a wormhole even 1 meter across would require [url=http://www.wired.com/wired/archive/6.07/es_wa rp_pr.html]the combined energy of the mass of the planet jupiter converted into exotic matter[/url].
Imagine if Apple adopted the Cell processor, with its PowerPC core and massive parallelism via SPEs. AltiVec, for example, could be emulated on the SPEs while the OS executes on the primary core. Then, new applications could be written to take advantage of the SPEs directly, leading to unheard of performance (200+ GFLOPS out of a single CPU)
And since the primary core is PPC to begin with, writing the emulation code for AltiVec and adding SPE support to OS X would be a HELL of a lot easier than integrating a PowerPC emulation into OS X. Look at how slow PearPC runs! Can you imagine running a large application like Photoshop through PPC/x86 emulation? It would be horrible!
XNU, the kernel of OS X, is a hybrid of Mach and select BSD code, which leans substantially more towards a monolithic kernel design. What Mach typically handled in a microkernel manner with servers, namely things like the VFS, networking, etc. have all been completely removed in XNU. Where once there were Mach servers there is now the FreeBSD Unified Buffer Cache, to which Apple has attached various FreeBSD subsystems like the FreeBSD VFS and network stack.
XNU is essentially a monolithic kernel, much like Linux. The real differences, in my opinion, lie in the IOKit object oriented driver API, whereas Linux has no real driver API and drivers have complete access to all kernel functions as drivers are simply kernel modules.
I administrate dozens of Solaris/SPARC systems over the years. While implementing a buffer overflow on this architecture may be less trivial, I can't tell you how many buffer overrun patches I've installed over the years in various patch clusters.
The real disadvantage of x86 over a RISC architecture like SPARC is that it doesn't have page protections (not to be confused with real mode segmentation which essentially disables the protected mode i386 MMU) where pages containing data and code are marked differently, so data pages are non-executable. sparcv9 implements a non-executable user stack per default, whereas it's a configurable option for sparcv8 binaries.
This has all changed with x86-64/AMD64/EM64T/x64/WHATEVER, which has brought a noexec bit to memory pages and allows hardware buffer overflow protection similar to SPARC. This still isn't a silver bullet for buffer overflows, but it's certainly better than nothing.
How about BeOS LiveQueries, created by Dominique Giampaolo who would later be hired by Apple to develop Spotlight?
Spotlight is largely an improvement on the ideas he developed with LiveQueries, adding natural language metadata searching to an OS that's pro-actively metadata oriented in the first place.
If anything, everyone else copied BeOS... the real difference is Spotlight is available to the public at the end of the month. With WinFS, who can say? 2007? 2008? 2009?
The open source world can look forward to Spotlight-like functionality once Beagle and inotify mature, the only real drawbacks are that it's currently rather unstable and written in.NET/Mono
...the fact that Slashdot has run about 30 "Dell might maybe possibly be thinking about considering using AMD processors" only to run a "Never mind Dell denies it" stories. How about holding off on running another pair of these stories until Dell officially confirms they're using AMD processors?
...and it's great there's a book covering it. There are so very many security related tools available today, and the real problem nowadays is that few of them integrate in any usable manner. NIDS should integrate with each other and generate more comprehensive, multiperspective data about suspicious looking traffic. Networks should autoadapt to block malicious traffic.
Moore's Law states that transistor counts double ever 12-24 months, which most have interpreted as 18 months. However, to quote Moore himself:
"I never said 18 months. I said one year, and then two years... Moore's Law has been the name given to everything that changes exponentially. I saw, if Gore invented the Internet, I invented the exponential"
...and therein lies its true flaw. As the law stipulates doubling transistor counts, as soon as processors are primarily developed with non-transistor based technologies, be they optical or quantum derived, Moore's Law is essentially defunct.
...is my recommended approach. I actually built one of these myself, powered by an embedded Linux PC that boots from CD-ROM. It uses modular exponentation to generate a cryptographically random sector distribution list, to which it writes entropy data generated from an onboard Random Event Generator. It repeats this process 10 times consecutively, then cuts power to the drive and degausses the entire disk. This process is extensive enough to ensure that even the world's most sophisticated data recovery experts will recovery nary a bit from such a drive, and I've automated it to a plug and play process. Simply insert the drive into the degaussing chamber and attach data and power cables, then throw the switch. Wait about an hour or so, and the drive comes out irrevocably blank.
NetBSD in particular and DragonFlyBSD to a lesser extent seem to be taking off in the wake of what seems like mass disillusionment in FreeBSD 5.x.
I certainly don't see any kind of "mass disillusionment". FreeBSD 5.x has brought about added complexity for the sake of performance, namely in the SMP and multithreading arenas. These are areas where you will find the performance of NetBSD rather lacking. While NetBSD may win at certain meaningless microbenchmarks, the real world performance of FreeBSD, especially on multiprocessor systems, will generally be quite better. NetBSD has always had its primary focus on portability, whereas FreeBSD's has been primarily on performance. Microbenchmarks indicate, if anything, that FreeBSD has chosen higher overhead implementations which increase overall performance, whereas NetBSD has implementations whose simplicity incurs lower overhead on microbenchmarks.
Firefly has taken a radically different approach and is attempting to refactor a BSD kernel into a more microkernel-like operating system. So while FreeBSD decided to take the SunOS/Solaris-like approach, DragonFly has gone the way of Mach. This is a rather fundamental design schism, and is more indicative that microkernel concepts are still quite valid than any kind of mass disillusionment over FreeBSD 5.x. I think it's great that they're introducing microkernel concepts to a stable and mature POSIX compatible OS rather than starting from scratch, but sadly I think DragonFly will be an OS that has trouble finding its niche.
Arch and Monotone are both GPL-licensed distributed development tools, and retain a BitKeeper-like distributed development model which Linux prefers.
Somehow Arch was immediately mentioned on the original thread about Linus's intent to switch away from BitKeeper, but somehow only Subversion has been mentioned on this one. Arch was created specifically with the goal of replacing BitKeeper as the SCM for the Linux kernel source, as it says on their web page:
It is somewhat well known, these days, that some of the core developers of the Linux kernel are using a revision control system which is not free software. There is a need to create a free software alternative to that system and to do so is one of the goals of the arch project
Don't you get it? How does the server distinguish between a legitimate copy of iTunes or another program like PyMusick that talks an identical wire protocol? Various programs have attempted to block 3rd party servers and clients (i.e. AIM, Warcraft) and the only way they've managed to be successful is using the DMCA to prosecute the people doing the reverse engineering. There's no way to prevent a client or server from talking the same wire protocol.
PyMusick could send the same public key, iTMS would send it the same song, and PyMusic could decrypt the song with its private key, yielding the same unencrypted, DRM-free file. Adding public key cryptography does nothing to solve the problem.
They could use private key cryptography, but the key would have to ship with every copy of iTunes, where it could be discovered through disassembly of the encryption algorithm. This is the exact approach KaZaA used, and it was reverse engineered, but 3rd party KaZaA clients were halted thanks to the DMCA.
Slashdot Mirror
"All jocks think about it sports. All nerds think about is sex." - Louis Skolnick, Revenge of the Nerds
I have a rather large master password list for every server at work which I store this way. It's quite handy.
Good question, especially considering FreeBSD Tinderbox has been doing this sort of thing for years, and not just with the kernel but with the entire base system.
GenoByte has found a more novel use for FPGAs, which they call "evolvable hardware." Much like our own brains neural networks on the FPGAs reconfigure the way they interconnect on the fly; commonly used paths are reenforced while less frequently used ones atrophy.
Here are some cool pictures:
The CAM-BRAIN machine, a big box full of FPGA boards: http://www.genobyte.com/images/machine.jpg
Neural network layout for the XC6216 FPGA: http://www.genobyte.com/images/chip.JPG
All in all this approach is substantially faster than modelling large neural networks on a general purpose processor. In the GenoByte approach, the neural network is implemented as physical circuits.
Let's not forget that even if these researchers are wrong and such a wormhole would be stable, opening a wormhole even 1 meter across would require [url=http://www.wired.com/wired/archive/6.07/es_wa rp_pr.html]the combined energy of the mass of the planet jupiter converted into exotic matter[/url].
And since the primary core is PPC to begin with, writing the emulation code for AltiVec and adding SPE support to OS X would be a HELL of a lot easier than integrating a PowerPC emulation into OS X. Look at how slow PearPC runs! Can you imagine running a large application like Photoshop through PPC/x86 emulation? It would be horrible!
XNU is essentially a monolithic kernel, much like Linux. The real differences, in my opinion, lie in the IOKit object oriented driver API, whereas Linux has no real driver API and drivers have complete access to all kernel functions as drivers are simply kernel modules.
Steve Jobs did SOOOOO much acid...
Opera 8.0 supports SVG, and so will IE7. Looks like all the top browsers will soon support SVG...
The real disadvantage of x86 over a RISC architecture like SPARC is that it doesn't have page protections (not to be confused with real mode segmentation which essentially disables the protected mode i386 MMU) where pages containing data and code are marked differently, so data pages are non-executable. sparcv9 implements a non-executable user stack per default, whereas it's a configurable option for sparcv8 binaries.
This has all changed with x86-64/AMD64/EM64T/x64/WHATEVER, which has brought a noexec bit to memory pages and allows hardware buffer overflow protection similar to SPARC. This still isn't a silver bullet for buffer overflows, but it's certainly better than nothing.
I contend that the abbreviation that redirects to the BBC's site is the correct one
Microsoft: proudly stealing Apple's ideas since Windows 1.0
Spotlight is largely an improvement on the ideas he developed with LiveQueries, adding natural language metadata searching to an OS that's pro-actively metadata oriented in the first place.
If anything, everyone else copied BeOS... the real difference is Spotlight is available to the public at the end of the month. With WinFS, who can say? 2007? 2008? 2009?
The open source world can look forward to Spotlight-like functionality once Beagle and inotify mature, the only real drawbacks are that it's currently rather unstable and written in .NET/Mono
...the fact that Slashdot has run about 30 "Dell might maybe possibly be thinking about considering using AMD processors" only to run a "Never mind Dell denies it" stories. How about holding off on running another pair of these stories until Dell officially confirms they're using AMD processors?
...and it's great there's a book covering it. There are so very many security related tools available today, and the real problem nowadays is that few of them integrate in any usable manner. NIDS should integrate with each other and generate more comprehensive, multiperspective data about suspicious looking traffic. Networks should autoadapt to block malicious traffic.
I would've personally prefered "From ash to zsh"
The WinTV PVR 250/350 cards are supported by MythTV through the ivtv drivers: http://ivtv.sourceforge.net/
...and therein lies its true flaw. As the law stipulates doubling transistor counts, as soon as processors are primarily developed with non-transistor based technologies, be they optical or quantum derived, Moore's Law is essentially defunct.
...is my recommended approach. I actually built one of these myself, powered by an embedded Linux PC that boots from CD-ROM. It uses modular exponentation to generate a cryptographically random sector distribution list, to which it writes entropy data generated from an onboard Random Event Generator. It repeats this process 10 times consecutively, then cuts power to the drive and degausses the entire disk. This process is extensive enough to ensure that even the world's most sophisticated data recovery experts will recovery nary a bit from such a drive, and I've automated it to a plug and play process. Simply insert the drive into the degaussing chamber and attach data and power cables, then throw the switch. Wait about an hour or so, and the drive comes out irrevocably blank.
I certainly don't see any kind of "mass disillusionment". FreeBSD 5.x has brought about added complexity for the sake of performance, namely in the SMP and multithreading arenas. These are areas where you will find the performance of NetBSD rather lacking. While NetBSD may win at certain meaningless microbenchmarks, the real world performance of FreeBSD, especially on multiprocessor systems, will generally be quite better. NetBSD has always had its primary focus on portability, whereas FreeBSD's has been primarily on performance. Microbenchmarks indicate, if anything, that FreeBSD has chosen higher overhead implementations which increase overall performance, whereas NetBSD has implementations whose simplicity incurs lower overhead on microbenchmarks.
Firefly has taken a radically different approach and is attempting to refactor a BSD kernel into a more microkernel-like operating system. So while FreeBSD decided to take the SunOS/Solaris-like approach, DragonFly has gone the way of Mach. This is a rather fundamental design schism, and is more indicative that microkernel concepts are still quite valid than any kind of mass disillusionment over FreeBSD 5.x. I think it's great that they're introducing microkernel concepts to a stable and mature POSIX compatible OS rather than starting from scratch, but sadly I think DragonFly will be an OS that has trouble finding its niche.
Somehow Arch was immediately mentioned on the original thread about Linus's intent to switch away from BitKeeper, but somehow only Subversion has been mentioned on this one. Arch was created specifically with the goal of replacing BitKeeper as the SCM for the Linux kernel source, as it says on their web page:
BOFHs are to be feared, not respected...
PyMusick could send the same public key, iTMS would send it the same song, and PyMusic could decrypt the song with its private key, yielding the same unencrypted, DRM-free file. Adding public key cryptography does nothing to solve the problem.
They could use private key cryptography, but the key would have to ship with every copy of iTunes, where it could be discovered through disassembly of the encryption algorithm. This is the exact approach KaZaA used, and it was reverse engineered, but 3rd party KaZaA clients were halted thanks to the DMCA.