Or CLIC or ILC etc. Well, I ain't complainin', it's a great way to spend government money. And the way I see it, not only does it keep us all in jobs, it's more money that the Illuminati will never be able to use to further immanentise the eschaton.
Hey: any evolved civilzation with the brains to travel at C will take one look at us, and fly on by
Any more-evolved civilisation with FTL technology would take one look at us, call in their anthropologists, and send a party down to study us because we so remind them of how they used to be, since they believe that by studying "lesser" civilisations they can better understand themselves.
As a Linux guy, I am also sad to see him leave and abandon his patchset. They were good patches, especially swap prefetch. Hopefully someone else will take it up and maintain it.
This seems to be an on-going trend in the kernel: FUSE, libusb, libraw1394 and ALSA all (to a certain extent) export what were traditionally kernel-bound services/drivers to user-space, while leaving the minimum necessary kernel-side mechanism, such as VFS redirection, and low-level I/O and interrupt handling. However they all do this in different ways according to the needs of the hardware. So while a generic API may be a good for unusual pieces of hardware, might it not be a good idea to develop application-specific subsystems that hook the kernel's existing ABIs (as used by current kernel-space drivers)? For example, we could have something specific for networking devices that does all the necessary set-up on the kernel side (establishing device name, wireless extensions, etc.) and communicates with a user-space driver (a bit like ALSA), which could be anything from a specific Free-Software driver to a proprietary modem driver or a wrapper for something like NDIS. Similarly with network protocols, although this might look more like FUSE.
My fascination is with how similar this is to the theory of free market economics.
I'm not too familiar, but there may be some universalities associated with them. Often seemingly different systems like these (e.g., in condensed matter systems and QFTs) composed of a large number of simple but linked elements exhibit similar behaviours (such as around phase transitions).
Slashdot Mirror
Or CLIC or ILC etc. Well, I ain't complainin', it's a great way to spend government money. And the way I see it, not only does it keep us all in jobs, it's more money that the Illuminati will never be able to use to further immanentise the eschaton.
Yep. I skimmed through the photos looking for grounding kit, too. Reminds me of that talk my dad had with me about inadequate protection.
No, hang on — seriously, what kind of person does this make me?!
And I'm Spartacus!
Any more-evolved civilisation with FTL technology would take one look at us, call in their anthropologists, and send a party down to study us because we so remind them of how they used to be, since they believe that by studying "lesser" civilisations they can better understand themselves.
And then they discover icanhascheezburger.com.
The only people stuck in RPM Hell are those too ignorant to learn how to use rpm or yum.
Sounds like you've got serious uptime on the mind.
So? Don't apply the firmware update.
OK, which joker modded me "Redundant"?
Thankfully, nautral lagnuage has evolved enough redudnancy to provide for fairly reliable error corectiuon.
Go watch Pink Floyd The Wall and post again.
As a Linux guy, I am also sad to see him leave and abandon his patchset. They were good patches, especially swap prefetch. Hopefully someone else will take it up and maintain it.
This seems to be an on-going trend in the kernel: FUSE, libusb, libraw1394 and ALSA all (to a certain extent) export what were traditionally kernel-bound services/drivers to user-space, while leaving the minimum necessary kernel-side mechanism, such as VFS redirection, and low-level I/O and interrupt handling. However they all do this in different ways according to the needs of the hardware. So while a generic API may be a good for unusual pieces of hardware, might it not be a good idea to develop application-specific subsystems that hook the kernel's existing ABIs (as used by current kernel-space drivers)? For example, we could have something specific for networking devices that does all the necessary set-up on the kernel side (establishing device name, wireless extensions, etc.) and communicates with a user-space driver (a bit like ALSA), which could be anything from a specific Free-Software driver to a proprietary modem driver or a wrapper for something like NDIS. Similarly with network protocols, although this might look more like FUSE.
No doubt there'll be some troll along shortly claiming that the GIMP suit is clunky and hard to use, and that they prefer a PhotoShop suit.
Aborted
13) Profit!
Like CSI, you know, dust the keyboards for prints.