I've been in your situation (I live in India, which I affectionately call "Hellholia", where I used to have a 1 GB/month cap, including both upload and download, and before that, was on dialup for about a year and a half), and I've found that the only browser that's worth using in low-bandwidth situations is Opera. Switch it to show cached images only, and use right click > Show Image to load up images in-place (something that seems to be foreign to Gecko-based browsers).
Block ads by using the no-ads proxy autoconfig script. If it blocks too much, you can use the convenient F12 quick-configuration menu to turn off proxies. Alternately, set up Privoxy, which will then block ads among other stuff.
As has been recommended elsewhere, use a caching proxy server such as Squid (you can modify one of the tunables in no-ads.pac to direct traffic to it, and you can configure Privoxy to chain to Squid as well); this should help a bit with YouTube videos that have loaded completely. (It will likely not help with partial downloads, however, and YouTube is a very good way to reach and exceed your cap, Internet video generally being expensive bandwidth-wise. Every second of YouTube's "normal-quality" video requires upwards of 25 kB, so a ten-minute video will expend 15 megabytes on its own.)
When you use rich Internet applications like GMail, opt for the cut-down "classic" versions rather than the AJAXy ones. This will save on the copious amount of JavaScript code and markup downloaded to make the slick interfaces happen. Similarly, when using sites such as BBC News, opt for text-only versions. When reading articles on websites, opt for the "Printer Friendy" versions of the pages (or, in the case of Reuters, "Single Page"). These substantially save on the excessive markup for automatic ad loading, navigation bars, sidebars, etc.
These things should both help the performance of your Internet connectivity and reduce the wastage of bandwidth, and you won't miss out on much.
I find it reliable, simple to use, and reasonable to configure. It is especially good if you still need to use Windows, but want to use a Linux OS.
I suppose it is if all you're doing is running a single VM in isolation, and the built-in NAT networking is good enough for your purposes. It isn't if you're running multiple VMs that need to interact with one another as well as physical hosts on a real Ethernet network.
Yeah I have seen a couple of doozies - but a few minutes Googling helped me sort the problems out. I like to know the source code is there should I need it to resolve problems.
See, the way I view it is that I shouldn't have to hit the source code for minor quibbles, and that readable, comprehensible error messages are far more valuable than available source. Most people cannot read or understand arbitrary source code or its structure (and this is even true of many programmers). Most people will, however, be able to tell what a proper error message is saying.
I think plenty of users wouldn't have the same restrictions as you do.
Probably. Most people don't run a 32-bit userspace with a 64-bit kernel. However, 64-bit guest support is a fundamental feature, and it's a restriction not to support 64-bit guests. Most of the guest OSes I run are 32-bit, but I do have some 64-bit Windows, Solaris and FreeBSD guest OSes that I want to virtualize. As it is right now, I have three options: VMware, Xen 3.x and kvm, of which VMware is the best-performing by far. VirtualBox, of course, doesn't support it.
I come from a windows background, and I find the GUI setup brilliant. I tried kvm, but I found it complex, and I couldn't get some features working (e.g. multi-core support, networking, ACPI problems). I would like multi-core support in VirtualBox but it isn't a biggie.
Perhaps you should give the free of charge VMware Server a try as well.
Yes. Debian also has an amd64 port. However, people (like me) who would like to use a 64-bit kernel (for instance, to make use of 8 GiB of RAM without having to use PAE, and to be able to build and use the occasional 64-bit app that might use the majority of that RAM) without compromising compatibility (for instance, with binary-only 32-bit codecs and browser plugins) will install a 32-bit distro and a 64-bit kernel. This is as true for Debian as it is for Ubuntu, even if Ubuntu doesn't ship a 64-bit kernel for their i386 port. (It's pretty easy to build a 64-bit kernel, even on a 32-bit distro.)
Yeah, er, when your needs grow beyond QEMU, re-evaluate this. Saying QEMU is the best of VirtualBox only marks you as a crackpot. VirtualBox's biggest advantages over QEMU include a far superior binary translation engine (superior to kqemu, that is; without kqemu, QEMU's performing full emulation of a Pentium) as well as far superior management tools.
And perhaps most consumers don't need bridge-mode networking. That doesn't mean it isn't an important feature to implement properly.
I know, I've actually set it up in this manner myself, though it's annoying to do so. But this isn't sufficient—you need to provide VirtualBox (and QEMU with or without kqemu, and KVM) two shell scripts to run the brctl addif and brctl delif commands when starting and stopping a VM respectively. This is external scripting that shouldn't be necessary for the end user to do.
VMware's installer is a pleasure to use compared to the futzing around with scripting that I get to do with VirtualBox. (And by the way, VMware Workstation 6.5 is getting an even newer installer that's even better than what they used to have.)
And a 32-bit userspace sure is supported with a 64-bit Linux kernel. Debian stable, testing and unstable, for instance, all package amd64 kernels in the i386 distribution, and they run perfectly fine. The Linux kernel provides what kernel developers call "compat" support for ioctls and system calls in order to support 32-bit user processes on a 64-bit kernel. (This is also what, for instance, enables nspluginwrapper to run on a 64-bit Linux system.)
(Additionally, if you look at any commercial UNIX, they all have 64-bit kernels with 32-bit userspaces, with only specific applications that need more than 2-3 GiB of virtual address space built as 64-bit binaries, because 64-bit apps use more memory and cache [due to the larger pointer/reference size used in data structures] and so actually run slower on non-x86-64 architectures. x86-64 is a special case primarily due to the presence of twice as many general-purpose registers.)
VirtualBox's greatest failing is that in using QEMU's I/O and networking code, they've made it a royal pain to set up bridged-mode networking on Linux hosts. You get to write two scripts, to add and remove a TAP device from a host-side bridge, and get to set up said bridge on the host yourself. Not only this, since the 2.6.18 kernel you need to run VirtualBox VMs as root (or set up sudo with/etc/sudoers not to prompt for a password and use it within your scripts), because only the superuser can manipulate the TAP/TUN devices; chmodding them writable by a particular privileged group is insufficient.
Compare to VMware, which handles all the bridging etc. by itself—much more convenient to use.
Then there are VirtualBox's "Guru meditations", obscure ERROR_MESSAGES_THAT_LOOK_LIKE_THIS and provide minimal information, often requiring perusal of the source code to figure out what's wrong. This is entirely unsuitable for end users as well as people whose time is valuable.
Finally, I tend to run a 64-bit kernel with 32-bit userspace. VirtualBox does not support this combination—it's either 32-bit kernel with 32-bit userspace or 64-bit kernel with 64-bit userspace. (VMware on the other hand does support 64-bit kernel with 32-bit userspace; its failing is that [as far as I know] there is no non-beta 64-bit userspace for VMware yet, though this will change with the release of VMware Server 2.0 and VMware Workstation 6.5.) This is only really a problem on Debian and Debian-derived distributions like Ubuntu, whose package manager (dpkg) is too incompetent to handle multiarch properly, despite work ongoing for about four years now, so the user has to set up a 64-bit chroot environment. (Fedora, RHEL and CentOS get this right; rpm can handle multiarch properly, so it's only a matter of installing the appropriate libraries there.)
VMware also supports 64-bit guests on certain processors. VirtualBox doesn't support 64-bit guests at all.
So in my view, between the two, VMware still wins, open source or no open source.
The paper describes how he did it -- he's taking advantage of the fact that a processor with HyperThreading allows both threads to use the same cache, and specifically allows one thread's memory accesses to evict the contents of cache lines formerly carrying data accessed by the other thread into memory. (This, by the way, is by design -- HT processors are supposed to allow the thread to share execution resources, including functional execution units and caches, to maximize resource utilization. Cutting the cache in half to be doled out between the threads will make the processor perform more like a Celeron.)
The exploit is performed via prior knowledge of the data structures and algorithms in use by the victim thread. By being able to infer parts of the key from the layout of recent memory accesses performed by the other thread, the attacker is able to recover some of the key. The layout of accesses is inferred by timing memory accesses in a pattern designed to make the cache thrash and figuring out what relative addresses might have changed recently.
To say that this would be a difficult exploit on a multiuser system running many different threads from many different processes would be a great understatement. Under a controlled environment with a thread whose use of data structures and algorithms is known in great detail, it's feasible to pull it off. However, "in the wild" it's likely to be much, much more challenging.
Sorry, but Havoc Pennington's influence has castrated GNOME. The few things you can change, you need to fire up gconf-editor for (remember NT 4 and the Registry Editor?).
I use KDE, unashamedly because it offers me options and one size most certainly does not fit all when it comes to UIs. Sane defaults, yes, but one man's sanity is another man's annoyance.
Under Havoc Pennington's influence, perfectly sane preferences such as the ability to turn off Nautilus' desktop icons disappeared between GNOME 2.0 and 2.2 off pref dialogs, with the prefs receding to the murky depths of the largely undocumented gconf system. Forgive me if I think he's GNOME's problem, not its savior.
Look for things like hotplug, HAL Project, the D-BUS Project, the kernel events layer and other components of Project Utopia to get you things like automagic USB device identification, driver loading and GUI events.
Hopefully we'll see something in GNOME 2.8/2.10/3.0 that'll use this stuff.
(See http://www.freedesktop.org; lots of cool stuff going on behind the scenes.)
See http://tech9.net/rml/talks/rml_fosdem_2004.sxi for more info.
You plug in the CompactFlash reader to a USB port, and it appears on the desktop. If your system is set up for it, GNOME then asks you "Would you like to import these photographss into your photo album?"
Not just this. Imagine what it'll do for home theater PCs that people build to handle everything from playing DVDs, playing CDs, MP3 CDs, act as a digital video recorder a la TiVO, and so on. You insert the medium, GNOME gets notified of the media attachment, mounts the volume for you, starts the appropriate media player, which starts playing the media. (Other controls can be done via LIRC and an infrared remote control.)
Want to keep this week's digital recordings around for next week? Press a button on your RCU to unmount the drive safely. Unplug the FireWire drive enclosure and remove the drive from the mobile rack fitted in it. Insert another drive, and plug the enclosure into the FireWire port. Hotplug detects the addition and sysfs and udev are updated. HAL picks up on this via dnotify/imon/whatever. It notifies gnome-volume-manager or whatever via D-BUS. The GNOME component automatically deals with discovering the filesystem and mounting it, doing an automatic fdisk + mkfs if needed. Then the DVR app starts up, and you can start recording whenever you wish.
All of this happens behind the scenes, with minimal interference from the end user. All you'd have to do would be to hit that button on your remote to prepare the system for disk removal, then you'd unplug the drive enclosure, pull the drive out, push another one in and reconnect it. That'd be all.
And this is just one application for Project Utopia. (Think about the question I asked RML about the network daemon being able to pick up on extra storage.)
Perhaps you'd wish to appreciate Ingo Molnar's work?
Robert Love's work has been to make the kernel mostly preemptible, rather than to make its scheduling algorithm more efficient.
The Pentium 4 is, in fact, designed to scale to high clock speeds exactly so that it can tolerate lots of pipeline bubbles in flight without ending up stalling for too long.
A lot of these tricks (high decode bandwidth, multiple instruction queues [really buffers meant for reordering the instruction stream], branch prediction, etc.) are meant to reduce hazards such as pipeline bubbles as far as possible, and the PPC 970 does these hazard-reducing operations rather well, too.
And, yes, we're now in the post-RISC world where instruction complexity (particularly in the realm of SIMD and streaming/explicit cache manipulation instructions) is growing because simple instructions clearly aren't enough to allow for great throughput increments.
(Read some of Stokes' older articles in the Ars Technopaedia; I'm sure you'll find them interesting.)
In fact, building 64-bit binaries willy-nilly can hurt performance, since 64-bit addresses and 64-bit integers take up more cache than 32-bit addresses and integers, so you can fit less of them in cache, and your miss rate goes up.
Combine this fact with the fact that memory is still much slower than the CPU's cache -- yes, even with the ~6.4 GB/s memory bandwidth available to the PPC 970 -- and it's still wiser to build 32-bit binaries for most applications.
Just build applications that either utilize a lot of memory or a lot of address space (e.g. memory-mapping huge files or large numbers of files) as 64-bit binaries, and you're set.
No, but IA-32 motherboard manufacturers go a good number of steps further.;)
I recommend that you investigate Intel's Placer (E7505) chipset and motherboards based on it (several of Supermicro's offerings, as well as offerings from Tyan and other manufacturers, e.g. the Iwill DPL533 and DP533.
These motherboards support 133 MHz QDR system buses (coming to 533 million transfers a second), matched (quite well) with two channels of PC2100 DDR SDRAM (resulting in 4.267 GB/s of memory bandwidth that is actually utilizable by the processors, since the memory bandwidth matches the system bus bandwidth, unlike Apple's offering, which is bottlenecked by the system bus at just 1.333 GB/s, whether you have one processor or two).
(And I'm certain that 200 MHz QDR Xeon chipsets are not far off in the future, since Intel in general appears to be headed in that direction.)
Did anyone else catch the bit on the twin FPU's? I'm just imagining what this thing is going to do with vector operations and frequency transforms.
For most of you non-engineers:
Most 3d vector operations are affine tranformations. Using a 4x4 array of floating point numbers you can translate, rotate, and scale. Works beautifully, but it's a lot of calculations.
The Fast Fourier Transform (FFT) is used a lot in signal processing. It's a floating point monster.
I would imagine that the use of AltiVec/VMX single-instruction multiple-data instructions would be somewhat more effective in doing vector and matrix floating-point computations than scalar floating-point operations as provided by the dual FPUs -- especially on these smaller (4x4, 8x8) matrices.
While, in comparison to the MPC 7450, the PPC 970 may have an inferior VMX unit (but with much more bandwidth and a higher clockspeed available), the SIMD instructions allow for more data to be processed per clock cycle than the scalar FPUs can, so I imagine that things like FFTs and vector arithmetic and transformations are better-suited to the use of AltiVec/VMX instructions -- perhaps even hand-tuned to get the best instruction scheduling and highest instructions-per-clock count (and hence computational throughput).
Re:No matter how many times I read it...
on
More on the PowerPC 970
·
· Score: 3, Informative
The vast majority of applications ought to run without modifications, since the instruction set is backward compatible (i.e. there are instructions for 64-bit addressing and with 64-bit-wide operands, but as far as I can tell, that's all). CPU-intensive applications would benefit from a recompile using a compiler that is aware of the PPC 970's unique pipelining and queueing, and can order instructions in the instruction stream that will allow for maximum execution unit utilization.
Some applications, e.g. large databases and applications that deal with very large integers, will benefit from being rebuilt with 64-bit addressing and 64-bit instructions, but for the vast majority of (desktop) applications that run on OS X, all 64-bit binaries will do is to increase the utilization of CPU instruction cache (and often data cache), and hence reduce performance as the cache miss rates go up.
So, in the end, don't worry; your OS X applications will run fine (for the most part) on a PowerPC 970-equipped Macintosh.;)
Many social psychological studies show catharsis not to be effective, i.e., the popular perception of aggression through games as being 'venting' is actually untrue. It only serves to reduce the effectiveness of the barrier to violent acts.
Some sort of third party big brother handling authentication. I'd much rather just have a cookie that I can turn on or off than have a third party take care of it for me. I trust me more than them.
It's a pretty well-accepted fact today that trusting the end user to keep his/her keys and identification information is a fallacy. Such systems are securable but not secure, since you can expect most people to be careless, and occasionally, for instance, leave themselves logged in, or in the case of strictly single-user operating systems like DOS and non-NT Windows, one can just turn the computer on and assume the identity of the person.
This means that there has to be a mechanism by which the server can know who you really are, without trusting you to keep your key or identification information lying around easily accessible through the computer. (This is still not failsafe, because, in the case of password-based authentication, you might still do something stupid like tape your password to your monitor, or keep it lying around . . . the possibilities are endless, and worsen with each additional secret key one has to keep.) One fairly elegant solution is to have a trusted third party, who you can sue if your information is divulged, etc. As long as you can put the blame on them after the fact, it will be a reasonable deterrent for them preventing them from being dishonest.
The reason for having a trusted third party is that neither side needs to be suspicious of the other side -- the client goes to the third party to find out how to talk to the other side, and the fact that the other side can understand our end of communication and we can understand the other end means that the connection is secured.
Another advantage is that the number of times the shared secret (or shared key) is used can be minimized -- a new temporary session key based on the nonce (a temporary, session-specific quantity calculated to prevent replay attacks) can be newly computed and passed to the client and the server, and thrown away later -- so that the more long-lived key -- such as a password, or principal-auth server key, or auth-server-to-service key -- have a minimal chance of being compromised.
So just because an individual is paranoid and can guarantee that he or she will never compromise security by leaving their account wide open for anyone to access, does not make this true in general. Most people are not bothered as much about security and secure transactions to keep their cookies inaccessible by an attacker. So for the general case, it is better to opt for a trusted third party, where the keyword is trust. Perhaps additional legislation and additional penalties would help to enforce this trust.
Slashdot Mirror
Or w3m, which is even better.
I've been in your situation (I live in India, which I affectionately call "Hellholia", where I used to have a 1 GB/month cap, including both upload and download, and before that, was on dialup for about a year and a half), and I've found that the only browser that's worth using in low-bandwidth situations is Opera. Switch it to show cached images only, and use right click > Show Image to load up images in-place (something that seems to be foreign to Gecko-based browsers).
Block ads by using the no-ads proxy autoconfig script. If it blocks too much, you can use the convenient F12 quick-configuration menu to turn off proxies. Alternately, set up Privoxy, which will then block ads among other stuff.
As has been recommended elsewhere, use a caching proxy server such as Squid (you can modify one of the tunables in no-ads.pac to direct traffic to it, and you can configure Privoxy to chain to Squid as well); this should help a bit with YouTube videos that have loaded completely. (It will likely not help with partial downloads, however, and YouTube is a very good way to reach and exceed your cap, Internet video generally being expensive bandwidth-wise. Every second of YouTube's "normal-quality" video requires upwards of 25 kB, so a ten-minute video will expend 15 megabytes on its own.)
When you use rich Internet applications like GMail, opt for the cut-down "classic" versions rather than the AJAXy ones. This will save on the copious amount of JavaScript code and markup downloaded to make the slick interfaces happen. Similarly, when using sites such as BBC News, opt for text-only versions. When reading articles on websites, opt for the "Printer Friendy" versions of the pages (or, in the case of Reuters, "Single Page"). These substantially save on the excessive markup for automatic ad loading, navigation bars, sidebars, etc.
These things should both help the performance of your Internet connectivity and reduce the wastage of bandwidth, and you won't miss out on much.
I suppose it is if all you're doing is running a single VM in isolation, and the built-in NAT networking is good enough for your purposes. It isn't if you're running multiple VMs that need to interact with one another as well as physical hosts on a real Ethernet network.
See, the way I view it is that I shouldn't have to hit the source code for minor quibbles, and that readable, comprehensible error messages are far more valuable than available source. Most people cannot read or understand arbitrary source code or its structure (and this is even true of many programmers). Most people will, however, be able to tell what a proper error message is saying.
Probably. Most people don't run a 32-bit userspace with a 64-bit kernel. However, 64-bit guest support is a fundamental feature, and it's a restriction not to support 64-bit guests. Most of the guest OSes I run are 32-bit, but I do have some 64-bit Windows, Solaris and FreeBSD guest OSes that I want to virtualize. As it is right now, I have three options: VMware, Xen 3.x and kvm, of which VMware is the best-performing by far. VirtualBox, of course, doesn't support it.
Perhaps you should give the free of charge VMware Server a try as well.
Yes. Debian also has an amd64 port. However, people (like me) who would like to use a 64-bit kernel (for instance, to make use of 8 GiB of RAM without having to use PAE, and to be able to build and use the occasional 64-bit app that might use the majority of that RAM) without compromising compatibility (for instance, with binary-only 32-bit codecs and browser plugins) will install a 32-bit distro and a 64-bit kernel. This is as true for Debian as it is for Ubuntu, even if Ubuntu doesn't ship a 64-bit kernel for their i386 port. (It's pretty easy to build a 64-bit kernel, even on a 32-bit distro.)
Yeah, er, when your needs grow beyond QEMU, re-evaluate this. Saying QEMU is the best of VirtualBox only marks you as a crackpot. VirtualBox's biggest advantages over QEMU include a far superior binary translation engine (superior to kqemu, that is; without kqemu, QEMU's performing full emulation of a Pentium) as well as far superior management tools.
And perhaps most consumers don't need bridge-mode networking. That doesn't mean it isn't an important feature to implement properly.
I know, I've actually set it up in this manner myself, though it's annoying to do so. But this isn't sufficient—you need to provide VirtualBox (and QEMU with or without kqemu, and KVM) two shell scripts to run the brctl addif and brctl delif commands when starting and stopping a VM respectively. This is external scripting that shouldn't be necessary for the end user to do.
VMware's installer is a pleasure to use compared to the futzing around with scripting that I get to do with VirtualBox. (And by the way, VMware Workstation 6.5 is getting an even newer installer that's even better than what they used to have.)
And a 32-bit userspace sure is supported with a 64-bit Linux kernel. Debian stable, testing and unstable, for instance, all package amd64 kernels in the i386 distribution, and they run perfectly fine. The Linux kernel provides what kernel developers call "compat" support for ioctls and system calls in order to support 32-bit user processes on a 64-bit kernel. (This is also what, for instance, enables nspluginwrapper to run on a 64-bit Linux system.)
(Additionally, if you look at any commercial UNIX, they all have 64-bit kernels with 32-bit userspaces, with only specific applications that need more than 2-3 GiB of virtual address space built as 64-bit binaries, because 64-bit apps use more memory and cache [due to the larger pointer/reference size used in data structures] and so actually run slower on non-x86-64 architectures. x86-64 is a special case primarily due to the presence of twice as many general-purpose registers.)
VirtualBox's greatest failing is that in using QEMU's I/O and networking code, they've made it a royal pain to set up bridged-mode networking on Linux hosts. You get to write two scripts, to add and remove a TAP device from a host-side bridge, and get to set up said bridge on the host yourself. Not only this, since the 2.6.18 kernel you need to run VirtualBox VMs as root (or set up sudo with /etc/sudoers not to prompt for a password and use it within your scripts), because only the superuser can manipulate the TAP/TUN devices; chmodding them writable by a particular privileged group is insufficient.
Compare to VMware, which handles all the bridging etc. by itself—much more convenient to use.
Then there are VirtualBox's "Guru meditations", obscure ERROR_MESSAGES_THAT_LOOK_LIKE_THIS and provide minimal information, often requiring perusal of the source code to figure out what's wrong. This is entirely unsuitable for end users as well as people whose time is valuable.
Finally, I tend to run a 64-bit kernel with 32-bit userspace. VirtualBox does not support this combination—it's either 32-bit kernel with 32-bit userspace or 64-bit kernel with 64-bit userspace. (VMware on the other hand does support 64-bit kernel with 32-bit userspace; its failing is that [as far as I know] there is no non-beta 64-bit userspace for VMware yet, though this will change with the release of VMware Server 2.0 and VMware Workstation 6.5.) This is only really a problem on Debian and Debian-derived distributions like Ubuntu, whose package manager (dpkg) is too incompetent to handle multiarch properly, despite work ongoing for about four years now, so the user has to set up a 64-bit chroot environment. (Fedora, RHEL and CentOS get this right; rpm can handle multiarch properly, so it's only a matter of installing the appropriate libraries there.)
VMware also supports 64-bit guests on certain processors. VirtualBox doesn't support 64-bit guests at all.
So in my view, between the two, VMware still wins, open source or no open source.
Gah. Let's try again.
n _kolivas
http://apcmag.com.nyud.net:8080/6735/interview_co
Coral cache in case it loads too slowly: 7 35/interview_con_kolivas</a>
The paper describes how he did it -- he's taking advantage of the fact that a processor with HyperThreading allows both threads to use the same cache, and specifically allows one thread's memory accesses to evict the contents of cache lines formerly carrying data accessed by the other thread into memory. (This, by the way, is by design -- HT processors are supposed to allow the thread to share execution resources, including functional execution units and caches, to maximize resource utilization. Cutting the cache in half to be doled out between the threads will make the processor perform more like a Celeron.)
The exploit is performed via prior knowledge of the data structures and algorithms in use by the victim thread. By being able to infer parts of the key from the layout of recent memory accesses performed by the other thread, the attacker is able to recover some of the key. The layout of accesses is inferred by timing memory accesses in a pattern designed to make the cache thrash and figuring out what relative addresses might have changed recently.
To say that this would be a difficult exploit on a multiuser system running many different threads from many different processes would be a great understatement. Under a controlled environment with a thread whose use of data structures and algorithms is known in great detail, it's feasible to pull it off. However, "in the wild" it's likely to be much, much more challenging.
Sorry, but Havoc Pennington's influence has castrated GNOME. The few things you can change, you need to fire up gconf-editor for (remember NT 4 and the Registry Editor?).
I use KDE, unashamedly because it offers me options and one size most certainly does not fit all when it comes to UIs. Sane defaults, yes, but one man's sanity is another man's annoyance.
Under Havoc Pennington's influence, perfectly sane preferences such as the ability to turn off Nautilus' desktop icons disappeared between GNOME 2.0 and 2.2 off pref dialogs, with the prefs receding to the murky depths of the largely undocumented gconf system. Forgive me if I think he's GNOME's problem, not its savior.
Look for things like hotplug, HAL Project, the D-BUS Project, the kernel events layer and other components of Project Utopia to get you things like automagic USB device identification, driver loading and GUI events.
Hopefully we'll see something in GNOME 2.8/2.10/3.0 that'll use this stuff.
(See http://www.freedesktop.org; lots of cool stuff going on behind the scenes.)
See http://tech9.net/rml/talks/rml_fosdem_2004.sxi for more info.
O_o
View menu -> View as List.
Resize window as needed.
Oh, look, it's a detailed columnized view.
Perhaps you'd wish to appreciate Ingo Molnar's work? Robert Love's work has been to make the kernel mostly preemptible, rather than to make its scheduling algorithm more efficient.
Hey, if I hadn't submitted it, someone else would have anyway. :p
The Pentium 4 is, in fact, designed to scale to high clock speeds exactly so that it can tolerate lots of pipeline bubbles in flight without ending up stalling for too long.
A lot of these tricks (high decode bandwidth, multiple instruction queues [really buffers meant for reordering the instruction stream], branch prediction, etc.) are meant to reduce hazards such as pipeline bubbles as far as possible, and the PPC 970 does these hazard-reducing operations rather well, too.
And, yes, we're now in the post-RISC world where instruction complexity (particularly in the realm of SIMD and streaming/explicit cache manipulation instructions) is growing because simple instructions clearly aren't enough to allow for great throughput increments.
(Read some of Stokes' older articles in the Ars Technopaedia; I'm sure you'll find them interesting.)
In fact, building 64-bit binaries willy-nilly can hurt performance, since 64-bit addresses and 64-bit integers take up more cache than 32-bit addresses and integers, so you can fit less of them in cache, and your miss rate goes up.
Combine this fact with the fact that memory is still much slower than the CPU's cache -- yes, even with the ~6.4 GB/s memory bandwidth available to the PPC 970 -- and it's still wiser to build 32-bit binaries for most applications.
Just build applications that either utilize a lot of memory or a lot of address space (e.g. memory-mapping huge files or large numbers of files) as 64-bit binaries, and you're set.
No, but IA-32 motherboard manufacturers go a good number of steps further. ;)
I recommend that you investigate Intel's Placer (E7505) chipset and motherboards based on it (several of Supermicro's offerings, as well as offerings from Tyan and other manufacturers, e.g. the Iwill DPL533 and DP533.
These motherboards support 133 MHz QDR system buses (coming to 533 million transfers a second), matched (quite well) with two channels of PC2100 DDR SDRAM (resulting in 4.267 GB/s of memory bandwidth that is actually utilizable by the processors, since the memory bandwidth matches the system bus bandwidth, unlike Apple's offering, which is bottlenecked by the system bus at just 1.333 GB/s, whether you have one processor or two).
(And I'm certain that 200 MHz QDR Xeon chipsets are not far off in the future, since Intel in general appears to be headed in that direction.)
The vast majority of applications ought to run without modifications, since the instruction set is backward compatible (i.e. there are instructions for 64-bit addressing and with 64-bit-wide operands, but as far as I can tell, that's all). CPU-intensive applications would benefit from a recompile using a compiler that is aware of the PPC 970's unique pipelining and queueing, and can order instructions in the instruction stream that will allow for maximum execution unit utilization.
;)
Some applications, e.g. large databases and applications that deal with very large integers, will benefit from being rebuilt with 64-bit addressing and 64-bit instructions, but for the vast majority of (desktop) applications that run on OS X, all 64-bit binaries will do is to increase the utilization of CPU instruction cache (and often data cache), and hence reduce performance as the cache miss rates go up.
So, in the end, don't worry; your OS X applications will run fine (for the most part) on a PowerPC 970-equipped Macintosh.
Pathetic.
Many social psychological studies show catharsis not to be effective, i.e., the popular perception of aggression through games as being 'venting' is actually untrue. It only serves to reduce the effectiveness of the barrier to violent acts.
It's a pretty well-accepted fact today that trusting the end user to keep his/her keys and identification information is a fallacy. Such systems are securable but not secure, since you can expect most people to be careless, and occasionally, for instance, leave themselves logged in, or in the case of strictly single-user operating systems like DOS and non-NT Windows, one can just turn the computer on and assume the identity of the person.
This means that there has to be a mechanism by which the server can know who you really are, without trusting you to keep your key or identification information lying around easily accessible through the computer. (This is still not failsafe, because, in the case of password-based authentication, you might still do something stupid like tape your password to your monitor, or keep it lying around . . . the possibilities are endless, and worsen with each additional secret key one has to keep.) One fairly elegant solution is to have a trusted third party, who you can sue if your information is divulged, etc. As long as you can put the blame on them after the fact, it will be a reasonable deterrent for them preventing them from being dishonest.
The reason for having a trusted third party is that neither side needs to be suspicious of the other side -- the client goes to the third party to find out how to talk to the other side, and the fact that the other side can understand our end of communication and we can understand the other end means that the connection is secured.
Another advantage is that the number of times the shared secret (or shared key) is used can be minimized -- a new temporary session key based on the nonce (a temporary, session-specific quantity calculated to prevent replay attacks) can be newly computed and passed to the client and the server, and thrown away later -- so that the more long-lived key -- such as a password, or principal-auth server key, or auth-server-to-service key -- have a minimal chance of being compromised.
So just because an individual is paranoid and can guarantee that he or she will never compromise security by leaving their account wide open for anyone to access, does not make this true in general. Most people are not bothered as much about security and secure transactions to keep their cookies inaccessible by an attacker. So for the general case, it is better to opt for a trusted third party, where the keyword is trust. Perhaps additional legislation and additional penalties would help to enforce this trust.