Yes; mm, cm, m, what are you measuring from? It could be the standard m, but then **37 it would get smaller, not larger.
Remember that in physical calculations, the unit is multiplied as well, not just the value. That's why acceleration is measured in "meters per second per second". If you differentiate one step further, it'll be "meters per second per second per second", and so on. If you don't specify the unit you're working with from the start, the values are *meaningless*.
4GB video RAM is not an issue on 32 bit because the only part of it the host system can address directly is the "aperture". This is the same as how you can use a 1TB disk even with a 32-bit OS and only 1GB RAM. They don't have to all line up directly. Unless I'm just taking modern operating system design for granted and Windows really does require a direct memory map from all video memory to system memory.
I have had two PSUs fail on me. One was in an expensive Dell workstation and it exploded overnight, leaving a very interesting smell. The other was an Antec provided with a case, and it just stopped working for no reason. I didn't think PSUs could suck so badly, but I've learned my lesson.
The trend has been that as a market for a commodity electronic product grows, even if workers are being laid off due to increased efficiency, either the volume the company has to produce increases and they need equal or greater workers anyway, or those same workers end up growing new companies. You don't hear of companies like Western Digital going under because they became "too" efficient.
More importantly, it's just not that big a deal. GigE performance on a good card is still limited by software, such as buffer sizes, MTU config, network stack implementation, application implementation, etc. but of course 10GigE is definitely a PCI-e only endeavour.
I've benchmarked onboard and PCI NICs and get over 850Mb/s throughputs with iperf and netperf. Sure you could get another 50-100Mb/s with PCI-e, but that's practically a rounding error.
Yeah, that was a riot, unlike the vanilla Oblivion where the main quest requires you to do good deeds regardless of your character, the Shivering Isles quest requires evil. Then Knights of the Nine is absurdly over-pious to the point of being downright tedious, such as having to not do anything evil just to use the equipment you earned from 5-10 hours of questing!
You're doing something wrong, probably video driver. Like a default install of XP, Ubuntu will use the unaccelerated VESA driver by default *if* it doesn't find an accelerated driver matching your card.
I'm all for fair and equal, free market economics, but if it looks like a whole industry is going down, not just a single company, fair and equal bailouts are the right thing to do. If any one industry fails, it could cause a chain reaction that stalls virtually all production and maintenance, and things degenerate into the stone age or at least third world.
Without RAM we don't have new computers, without new computers we can't even sustain the infrastructure we have, let alone grow it to keep up with new demand and progress. Recycling everything can only take you so far, especially with computer parts whose MTBF is a few years.
Linux can boot into kernel, drivers and text console in under 30MB on a modern machine. A graphical interface takes more, and Ubuntu's very rich interface takes more still, but if Vista's kernel and drivers takes 10x as much memory as Linux' kernel and drivers, I would say Microsoft itself needs to be swallowed whole by the earth and cast back into the hell from which it emerged.
So you'd prefer to re-access the hard disk for every read instead of keeping valid data in memory? The 1960s called, they want their performance problems back.
That's why Ubuntu is growing in popularity... it's about as efficient as XP while still including all of the useful features of Vista, like integrated search and composited desktop. Boots into about 200-300MB RAM used, which is 2-3x smaller than Vista, leaving room to virtualise Windows XP for your legacy applications.
You can use badblocks in Linux to exercise each block. If you're storing checksums you should assert those as well. At least you'll know very quickly which files are lost and need to be recovered from backup.
This is vastly overkill. I find it's a lot simpler to just keep your most valuable data all organized and checksummed, calculating the checksum as soon as you have the data, and replicating this wherever you have space. If you don't trust the privacy of the storage you're replicating to, archive encrypt the data as well, and then checksum that too. Digitally sign it if you're extra paranoid.
If you just keep re-replicating, even just as you buy new computers and external disks, you'll find that by the time any single disk fails, you already have 5-10 copies. By the time the next disk fails, you might even have 15 or 20. They're all still checksummed and it's virtually impossible for all of them to be corrupted in the same ways. Even if one copy loses one file, the other copies still have it.
If you're trying to design a hardcore backup solution for copied movies, games, music, etc. it's a waste of time and money. It's probably cheaper to re-acquire whatever is corrupted or lost, than to prevent its loss through highly redundant and contrived archival methods.
Below the filesystem. ZFS can export zvols, which are just block devices whose storage maps on to ZFS blocks. They get checksumming and copy-on-write semantics, even snapshotting, and yet still support any filesystem on top, a whole partition table, a virtual machine disk, or whatever. They're just block devices, but they still get most of the reliability advantages of ZFS itself.
It's not as efficient as storing a ZFS filesystem which can track its used/free space and feed that in to the reliability systems, but if you want reliability, you get a lot of it for zero effort.
What I'm saying is that, as far as I understand, the same volume reliability features can be implemented for Linux without a new filesystem. You'd just have a new integration of existing RAID and block mapping features, plus block level checksumming and copy-on-write (feeding in to the device mapper). Even RAID-Z could be implemented in this way without needing a new filesystem. You can already run Linux filesystems over iSCSI to a zvol, so why not just implement the zvol directly in Linux?
Or they could just run enterprise Linux or Solaris servers, with filesystems that don't crap their pants and need mommy to clean up after them. It must be humiliating to have to schedule regular downtime just to amortise the cost of Windows' sheer stupidity.
I don't know where it fits either, but ZFS and eventually BTRFS actually have checksums at the block level, and can heal over corrupted blocks using redundant copies whose checksums do work. That alone is enough reason to use ZFS for a file server, but similar improvements could be made inside the Linux stack without a new filesystem on top. However ZFS' reliability also comes from copy-on-write updates which is not trivially installed into an existing filesystem.
Very technically, a byte can be four bits, it's an octet that specifies 8. Bytes have been defined as 7 bits on some architectures. But still, if you have to give a single straight answer, 8 is much better than 4.
It's true that JRuby has no overall GIL, but it definitely has plenty of internal fine-grained locks to maintain consistency and determinism. However thanks to Java 6 optimisations, almost all of those locks are completely elided while running a single-threaded program. That's just another way JRuby benefits from JVM technology, and yet another thing a C implementation cannot reasonably implement.
Slashdot Mirror
Yes; mm, cm, m, what are you measuring from? It could be the standard m, but then **37 it would get smaller, not larger.
Remember that in physical calculations, the unit is multiplied as well, not just the value. That's why acceleration is measured in "meters per second per second". If you differentiate one step further, it'll be "meters per second per second per second", and so on. If you don't specify the unit you're working with from the start, the values are *meaningless*.
4GB video RAM is not an issue on 32 bit because the only part of it the host system can address directly is the "aperture". This is the same as how you can use a 1TB disk even with a 32-bit OS and only 1GB RAM. They don't have to all line up directly. Unless I'm just taking modern operating system design for granted and Windows really does require a direct memory map from all video memory to system memory.
I have had two PSUs fail on me. One was in an expensive Dell workstation and it exploded overnight, leaving a very interesting smell. The other was an Antec provided with a case, and it just stopped working for no reason. I didn't think PSUs could suck so badly, but I've learned my lesson.
Every time you use an unspecified unit as the base in an exponential function, baby Newton cries.
The trend has been that as a market for a commodity electronic product grows, even if workers are being laid off due to increased efficiency, either the volume the company has to produce increases and they need equal or greater workers anyway, or those same workers end up growing new companies. You don't hear of companies like Western Digital going under because they became "too" efficient.
More importantly, it's just not that big a deal. GigE performance on a good card is still limited by software, such as buffer sizes, MTU config, network stack implementation, application implementation, etc. but of course 10GigE is definitely a PCI-e only endeavour.
Thank you FOSS for making all of this possible.
If it weren't for FOSS, Apple and OSX would be dead and all of this history and cool code would be gone.
So once again, THANK YOU FOSS, for doing what no one else can or could ever do.
Think different. Think better. THINK FOSS.
I've benchmarked onboard and PCI NICs and get over 850Mb/s throughputs with iperf and netperf. Sure you could get another 50-100Mb/s with PCI-e, but that's practically a rounding error.
Yeah, that was a riot, unlike the vanilla Oblivion where the main quest requires you to do good deeds regardless of your character, the Shivering Isles quest requires evil. Then Knights of the Nine is absurdly over-pious to the point of being downright tedious, such as having to not do anything evil just to use the equipment you earned from 5-10 hours of questing!
jint == int32_t
jlong == int64_t
Deal with it. When 128 becomes an issue there'll be a jlonger, or something like that. (jquad may be used for quad precision float)
You're doing something wrong, probably video driver. Like a default install of XP, Ubuntu will use the unaccelerated VESA driver by default *if* it doesn't find an accelerated driver matching your card.
I'm all for fair and equal, free market economics, but if it looks like a whole industry is going down, not just a single company, fair and equal bailouts are the right thing to do. If any one industry fails, it could cause a chain reaction that stalls virtually all production and maintenance, and things degenerate into the stone age or at least third world.
Without RAM we don't have new computers, without new computers we can't even sustain the infrastructure we have, let alone grow it to keep up with new demand and progress. Recycling everything can only take you so far, especially with computer parts whose MTBF is a few years.
Linux can boot into kernel, drivers and text console in under 30MB on a modern machine. A graphical interface takes more, and Ubuntu's very rich interface takes more still, but if Vista's kernel and drivers takes 10x as much memory as Linux' kernel and drivers, I would say Microsoft itself needs to be swallowed whole by the earth and cast back into the hell from which it emerged.
So you'd prefer to re-access the hard disk for every read instead of keeping valid data in memory? The 1960s called, they want their performance problems back.
That's why Ubuntu is growing in popularity... it's about as efficient as XP while still including all of the useful features of Vista, like integrated search and composited desktop. Boots into about 200-300MB RAM used, which is 2-3x smaller than Vista, leaving room to virtualise Windows XP for your legacy applications.
Sampling and encoding the events before they hit the limited USB connection is. That requires extra equipment, however.
You can use badblocks in Linux to exercise each block. If you're storing checksums you should assert those as well. At least you'll know very quickly which files are lost and need to be recovered from backup.
This is vastly overkill. I find it's a lot simpler to just keep your most valuable data all organized and checksummed, calculating the checksum as soon as you have the data, and replicating this wherever you have space. If you don't trust the privacy of the storage you're replicating to, archive encrypt the data as well, and then checksum that too. Digitally sign it if you're extra paranoid.
If you just keep re-replicating, even just as you buy new computers and external disks, you'll find that by the time any single disk fails, you already have 5-10 copies. By the time the next disk fails, you might even have 15 or 20. They're all still checksummed and it's virtually impossible for all of them to be corrupted in the same ways. Even if one copy loses one file, the other copies still have it.
If you're trying to design a hardcore backup solution for copied movies, games, music, etc. it's a waste of time and money. It's probably cheaper to re-acquire whatever is corrupted or lost, than to prevent its loss through highly redundant and contrived archival methods.
Below the filesystem. ZFS can export zvols, which are just block devices whose storage maps on to ZFS blocks. They get checksumming and copy-on-write semantics, even snapshotting, and yet still support any filesystem on top, a whole partition table, a virtual machine disk, or whatever. They're just block devices, but they still get most of the reliability advantages of ZFS itself.
It's not as efficient as storing a ZFS filesystem which can track its used/free space and feed that in to the reliability systems, but if you want reliability, you get a lot of it for zero effort.
What I'm saying is that, as far as I understand, the same volume reliability features can be implemented for Linux without a new filesystem. You'd just have a new integration of existing RAID and block mapping features, plus block level checksumming and copy-on-write (feeding in to the device mapper). Even RAID-Z could be implemented in this way without needing a new filesystem. You can already run Linux filesystems over iSCSI to a zvol, so why not just implement the zvol directly in Linux?
Or they could just run enterprise Linux or Solaris servers, with filesystems that don't crap their pants and need mommy to clean up after them. It must be humiliating to have to schedule regular downtime just to amortise the cost of Windows' sheer stupidity.
I run a RAIV-5 array, you insensitive clod!
I don't know where it fits either, but ZFS and eventually BTRFS actually have checksums at the block level, and can heal over corrupted blocks using redundant copies whose checksums do work. That alone is enough reason to use ZFS for a file server, but similar improvements could be made inside the Linux stack without a new filesystem on top. However ZFS' reliability also comes from copy-on-write updates which is not trivially installed into an existing filesystem.
If you sell 5x the units you'll pay for 5x the support. Support is an ongoing cost if you want ongoing users.
Very technically, a byte can be four bits, it's an octet that specifies 8. Bytes have been defined as 7 bits on some architectures. But still, if you have to give a single straight answer, 8 is much better than 4.
It's true that JRuby has no overall GIL, but it definitely has plenty of internal fine-grained locks to maintain consistency and determinism. However thanks to Java 6 optimisations, almost all of those locks are completely elided while running a single-threaded program. That's just another way JRuby benefits from JVM technology, and yet another thing a C implementation cannot reasonably implement.