While there's truth to what you're saying, there's also a strong(er) argument on the other side: there's a reason people died fighting to unionize in the relatively-recent past. (It's not like it is loads of fun to walk on a picket line.) Stating the obvious: unions provide an extremely potent and necessary check to provide balance. Think sweatshops overseas.
It's easy to bash unions for being sloppy, wasteful and laziness-promoting; you could apply the same shallow thinking on the US federal government system: "why do we need a Congress anyway? It only costs the taxpayers, and they don't get any work done", ad nauseaum. But that line of reasoning only shows your lack of thought on the topic. At least, in my opinion.:)
Correction: PCI Express, not PC Express. It has also been known as "3GIO" for the 3rd-Generation I/O bus. Generally the replacement for classic 32/64-bit parallel PCI. It scales in bandwidth by adding additional lanes (so you could have 1 lane, or 2 lanes, or 4 lanes, etc.) to the logical link.
PCI 2.3 ("classic") cards will not be able to plug into PCI Express slots, the form-factor and keying--everything--is different between the two applications. However, OEMs may place a PCI Express to PCI "Classic" bridge off one of the PCI Express root ports to provide the backwards support (if the southbridge doesn't already contain the PCI classic bus support.)
There used to be a kernel module you could use in the 2.2.x or maybe even 2.1.x days which would allow you to modify the TCP/IP signature in various ways; if they were really going to attempt this, then every distribution would merely have to enable such a technique with random "signatures.", right?
Many companies in the entertainment as well as computer chip design industries use rooms full of cheap x86 machines to perform the bulk of their batch processing. _That's_ where they're hitting the 4GB-per-process problem. We're running Linux on hundreds of Pentium III/4s, and with kernel tweaking are getting around 3.2GB per process. But even that's not enough for many job types...
It is amazing how the industry moves when licensing fees are involved.:) Apple wanted $1 (so I heard) per FireWire (or IEEE 1394A, B, etc.) device, so Intel said "no thanks" and didn't include it on it's chipsets. Similar for other chipset developers.
But as USB has no licensing fees for developers, people flock to it, despite 1394's obvious technical superiority.
Interestingly, one of the first things I heard about Malaysia (after a friend returned from a business trip) was that they have moved pretty strongly to cellular phones instead of land-line based phones. The reason being that it is far easier/cheaper to construct towers than it is to lay lines.
I would imagine that this follows for the USA in regards to broadband: it is easier to put up towers on top of buildings, etc. than to lay fiber, and connect the fiber to the end-users. So, my prognostication is that wireless (in general) will win out over fiber in the end.
Are you implying that you store all the world texture maps in-memory, all the time? Why wouldn't you instead scale the data to fit the current resolution for the current viewpoint of the globe? In other words, if you fit the entire glob into a 1280x1024 pixel screen, the display's resolution limits what you can see on the surface of the earth, why put more, unnecessary, data into memory?
I would imagine that depending on what your zoom factor is, and with culling of the unviewable hemisphere, etc., you don't need all that data in memory at once. Put a really fast SCSI/RAID subsystem in there to maximize disk throughput, and rely upon retrieving needed data on-the-fly if you go to rotate the glob etc.
I strongly disagree with that opinion: if you think about how people interact with web applications, GTK applications, Qt applications, or even simple ones using Athena etc., the widget system they use is mostly irrelavant. Most widgets are capable of being programmed in such a manner to provide a similar user experience: enough so as to make this discussion moot.
The bigger issue is to stick to standards such as where to place the "Help" pulldown menu on a window, where to place tabs or radio buttons, etc. That is the responsibility of the programmer, and not an issue with the widgets, or the fact that there is choice.
Or Microsoft could use NFS/CUPS/etc. Or when they come up with a new standard, they could publish the RFCs etc., interoperability would not be a concern, right?
Eh, isn't the armor from the US battle tanks a joint development with the British military? I thought I saw on Discovery Channel that the "Chobam" (don't recall the spelling) armor was the best yet, developed by the British...
I've got a dual-2GHz Prestonia (P4 "Xeon"), and without hyperthreading, a Linux kernel (2.4.19-pre-something with patches or IRQ balancing) compile takes about 3.5 minutes, whereas with hyperthreading enabled takes just over 2 minutes. Something like that. But, when running 4 instances of dnetc on hyperthreading you get slightly less than half the key throughput of just 2 instances with hyperthreading disabled. So, I usually just disable it and run dnetc.:)
To a large extent, yes, but recall that Alan Cox and others (Ingo Molnar?) are on RedHat's payroll, and there are lots of guys fixing bugs, writing test suites, etc. inside RedHat polishing their distributions up. Then they've got extended versions of Apache, etc. for bigger customers. So maybe at first this was true, but they've given back quite a bit to the community.
For ext2, I'd contrive something like this (for the [Ba]sh shell) to record the attributes:
for i in `grep ext2/etc/fstab | awk "{print \\$2}"`; do lsattr -R $i; done > attributes.manifest
and archive that along with the other files in the.tar archive. Then, cobble together a script to operate on that file to re-set the attributes when you unarchive the.tar file.
Hackish, yes, but completely doable in the user space, and can be done with whatever archival tool you like (tar, cpio, etc.)
No, the 8088 was a 8086 (16-bit data bus and registers: AX, BX, CX, DX) except the data bus was 8bits only (cheaper.) Both could address only 1MB of memory.
The 8086 came out in June 8, 1978, and the 8088 came out a year later. Both had roughly the same gate-count, at 29 000 transistors (3 micron process.)
The 80286 introduced (in Feb. of '82) 32bit extensions to the registers, giving you EAX, EBX, ECX, EDX, etc., and could address 16MB of memory. It was on the 1.5 micron process, and weighed in at 134 000 transistors.
A side note: my IBM Personal Portable PC has an AMD 8088 running at 8MHz, and achieves 0.31 BogoMips running ELKs (a very trimmed down Linux kernel.):)
That's funny. Or, to put this another way, "Either you may tell where it is with certainty, and not its velocity, or its velocity but not where it actually is with certainty.":)
It seems like the Tualatin is being pushed into the low-power (hence cooler-running) dense rack-mount 1U configuration. Where the P4 is having difficulty going due to it's thermal requirements. So for the mainstream, you won't see the Tualatin core. At least that's what I've seen reading several different mobo. vendors sites.
More important than latency and bandwidth (at least to OEMs) is routability. A RIMM has far fewer pins (due to the 16-bit bus etc.) than a DIMM, so creating a motherboard with Rambus memory is far easier (in fewer PCB layers) than with DDR. That makes Rambus easier to expand upon in the future, and makes putting yet another bandaid on DDR that much more difficult/unlikely.
Now if Rambus wasn't such an ugly company, and so on....
I do this with FVWM2: I have a 4x3 virtual desktop arrangement, where the user can use Ctrl- to move around in arbitrary directions, and also F[9-12] for any desktops in the first row, Ctrl-F[9-12] to select the columns in the second row, Ctrl-Alt-F[9-12] for the third row. I did this so the user doesn't have to arrow-arrow-arrow around to move around, which can be slow on slow machines especially with complicated windows to redraw on each display. This way, the user can go directly to any of the 12 desktops. That, and the other features on FVWM2's pager has kept me with it.
The IDE drives and host controller are designed in a very simple way, in which the host can only take data from the drive straight to memory. The most efficient IDE data transfer method is through DMA (direct memory access) where the IDE host controller logic takes data from the drive and places it in memory. (This requires no direct involvement in the CPU, other than setting the transfer up.) So, drive to memory, no opportunity for drive to drive.
On the other hand, for PIO (Programmed I/O) IDE cycles, the CPU has to actually move the data around byte by byte from memory to drive, which prevents the CPU from doing other work in the mean time (so the DMA is preferred), but I can't think right off why the CPU couldn't take data from one drive in PIO mode, and write it to the other (in PIO mode also.) Both data streams would have to be synchronized pretty closely. *shrugs* Don't know.
Don't know about SCSI drivers, but with IDE the data stream goes from drive to host (computer) memory, there's no path from Drive to Drive (master to slave or vice versa.) Additionally, each controller (primary and secondary) are effectively copies of eachother (just with their registers at different I/O offsets), so again software drivers are limited to drive to host memory transfers, not drive to drive. It's an IDE architecture limitation. It wouldn't surprise me if the same stood for SCSI.
Slashdot Mirror
I wish I had some moderator points to bump this up on Insightful...
While there's truth to what you're saying, there's also a strong(er) argument on the other side: there's a reason people died fighting to unionize in the relatively-recent past. (It's not like it is loads of fun to walk on a picket line.) Stating the obvious: unions provide an extremely potent and necessary check to provide balance. Think sweatshops overseas.
:)
It's easy to bash unions for being sloppy, wasteful and laziness-promoting; you could apply the same shallow thinking on the US federal government system: "why do we need a Congress anyway? It only costs the taxpayers, and they don't get any work done", ad nauseaum. But that line of reasoning only shows your lack of thought on the topic. At least, in my opinion.
Correction: PCI Express, not PC Express. It has also been known as "3GIO" for the 3rd-Generation I/O bus. Generally the replacement for classic 32/64-bit parallel PCI. It scales in bandwidth by adding additional lanes (so you could have 1 lane, or 2 lanes, or 4 lanes, etc.) to the logical link.
PCI 2.3 ("classic") cards will not be able to plug into PCI Express slots, the form-factor and keying--everything--is different between the two applications. However, OEMs may place a PCI Express to PCI "Classic" bridge off one of the PCI Express root ports to provide the backwards support (if the southbridge doesn't already contain the PCI classic bus support.)
There used to be a kernel module you could use in the 2.2.x or maybe even 2.1.x days which would allow you to modify the TCP/IP signature in various ways; if they were really going to attempt this, then every distribution would merely have to enable such a technique with random "signatures.", right?
Many companies in the entertainment as well as computer chip design industries use rooms full of cheap x86 machines to perform the bulk of their batch processing. _That's_ where they're hitting the 4GB-per-process problem. We're running Linux on hundreds of Pentium III/4s, and with kernel tweaking are getting around 3.2GB per process. But even that's not enough for many job types...
Sounds like an Onion article (www.theonion.com).
It is amazing how the industry moves when licensing fees are involved. :) Apple wanted $1 (so I heard) per FireWire (or IEEE 1394A, B, etc.) device, so Intel said "no thanks" and didn't include it on it's chipsets. Similar for other chipset developers.
But as USB has no licensing fees for developers, people flock to it, despite 1394's obvious technical superiority.
Interestingly, one of the first things I heard about Malaysia (after a friend returned from a business trip) was that they have moved pretty strongly to cellular phones instead of land-line based phones. The reason being that it is far easier/cheaper to construct towers than it is to lay lines.
I would imagine that this follows for the USA in regards to broadband: it is easier to put up towers on top of buildings, etc. than to lay fiber, and connect the fiber to the end-users. So, my prognostication is that wireless (in general) will win out over fiber in the end.
Are you implying that you store all the world texture maps in-memory, all the time? Why wouldn't you instead scale the data to fit the current resolution for the current viewpoint of the globe? In other words, if you fit the entire glob into a 1280x1024 pixel screen, the display's resolution limits what you can see on the surface of the earth, why put more, unnecessary, data into memory?
I would imagine that depending on what your zoom factor is, and with culling of the unviewable hemisphere, etc., you don't need all that data in memory at once. Put a really fast SCSI/RAID subsystem in there to maximize disk throughput, and rely upon retrieving needed data on-the-fly if you go to rotate the glob etc.
Just curious....
I strongly disagree with that opinion: if you think about how people interact with web applications, GTK applications, Qt applications, or even simple ones using Athena etc., the widget system they use is mostly irrelavant. Most widgets are capable of being programmed in such a manner to provide a similar user experience: enough so as to make this discussion moot.
The bigger issue is to stick to standards such as where to place the "Help" pulldown menu on a window, where to place tabs or radio buttons, etc. That is the responsibility of the programmer, and not an issue with the widgets, or the fact that there is choice.
At least, that's my opinion.
Or Microsoft could use NFS/CUPS/etc. Or when they come up with a new standard, they could publish the RFCs etc., interoperability would not be a concern, right?
Eh, isn't the armor from the US battle tanks a joint development with the British military? I thought I saw on Discovery Channel that the "Chobam" (don't recall the spelling) armor was the best yet, developed by the British...
Second the motion! All in favor...
I've got a dual-2GHz Prestonia (P4 "Xeon"), and without hyperthreading, a Linux kernel (2.4.19-pre-something with patches or IRQ balancing) compile takes about 3.5 minutes, whereas with hyperthreading enabled takes just over 2 minutes. Something like that. But, when running 4 instances of dnetc on hyperthreading you get slightly less than half the key throughput of just 2 instances with hyperthreading disabled. So, I usually just disable it and run dnetc. :)
Mod parent up. References from Tron out of the blue, that's good. :)
To a large extent, yes, but recall that Alan Cox and others (Ingo Molnar?) are on RedHat's payroll, and there are lots of guys fixing bugs, writing test suites, etc. inside RedHat polishing their distributions up. Then they've got extended versions of Apache, etc. for bigger customers. So maybe at first this was true, but they've given back quite a bit to the community.
For ext2, I'd contrive something like this (for the [Ba]sh shell) to record the attributes:
/etc/fstab | awk "{print \\$2}"`; do lsattr -R $i; done > attributes.manifest
.tar archive. Then, cobble together a script to operate on that file to re-set the attributes when you unarchive the .tar file.
for i in `grep ext2
and archive that along with the other files in the
Hackish, yes, but completely doable in the user space, and can be done with whatever archival tool you like (tar, cpio, etc.)
No, the 8088 was a 8086 (16-bit data bus and registers: AX, BX, CX, DX) except the data bus was 8bits only (cheaper.) Both could address only 1MB of memory.
:)
The 8086 came out in June 8, 1978, and the 8088 came out a year later. Both had roughly the same gate-count, at 29 000 transistors (3 micron process.)
The 80286 introduced (in Feb. of '82) 32bit extensions to the registers, giving you EAX, EBX, ECX, EDX, etc., and could address 16MB of memory. It was on the 1.5 micron process, and weighed in at 134 000 transistors.
A side note: my IBM Personal Portable PC has an AMD 8088 running at 8MHz, and achieves 0.31 BogoMips running ELKs (a very trimmed down Linux kernel.)
That's funny. Or, to put this another way, "Either you may tell where it is with certainty, and not its velocity, or its velocity but not where it actually is with certainty." :)
It seems like the Tualatin is being pushed into the low-power (hence cooler-running) dense rack-mount 1U configuration. Where the P4 is having difficulty going due to it's thermal requirements. So for the mainstream, you won't see the Tualatin core. At least that's what I've seen reading several different mobo. vendors sites.
More important than latency and bandwidth (at least to OEMs) is routability. A RIMM has far fewer pins (due to the 16-bit bus etc.) than a DIMM, so creating a motherboard with Rambus memory is far easier (in fewer PCB layers) than with DDR. That makes Rambus easier to expand upon in the future, and makes putting yet another bandaid on DDR that much more difficult/unlikely.
Now if Rambus wasn't such an ugly company, and so on....
I do this with FVWM2: I have a 4x3 virtual desktop arrangement, where the user can use Ctrl- to move around in arbitrary directions, and also F[9-12] for any desktops in the first row, Ctrl-F[9-12] to select the columns in the second row, Ctrl-Alt-F[9-12] for the third row. I did this so the user doesn't have to arrow-arrow-arrow around to move around, which can be slow on slow machines especially with complicated windows to redraw on each display. This way, the user can go directly to any of the 12 desktops. That, and the other features on FVWM2's pager has kept me with it.
The IDE drives and host controller are designed in a very simple way, in which the host can only take data from the drive straight to memory. The most efficient IDE data transfer method is through DMA (direct memory access) where the IDE host controller logic takes data from the drive and places it in memory. (This requires no direct involvement in the CPU, other than setting the transfer up.) So, drive to memory, no opportunity for drive to drive.
On the other hand, for PIO (Programmed I/O) IDE cycles, the CPU has to actually move the data around byte by byte from memory to drive, which prevents the CPU from doing other work in the mean time (so the DMA is preferred), but I can't think right off why the CPU couldn't take data from one drive in PIO mode, and write it to the other (in PIO mode also.) Both data streams would have to be synchronized pretty closely. *shrugs* Don't know.
Don't know about SCSI drivers, but with IDE the data stream goes from drive to host (computer) memory, there's no path from Drive to Drive (master to slave or vice versa.) Additionally, each controller (primary and secondary) are effectively copies of eachother (just with their registers at different I/O offsets), so again software drivers are limited to drive to host memory transfers, not drive to drive. It's an IDE architecture limitation. It wouldn't surprise me if the same stood for SCSI.