We finally get video and sound working properly and it's just been driving me BATTY when I have 30 firefox tabs open and can't figure out which one is making all the noise.
My absolute favorite is actually when a video site has video ads on the side bars that play over the video in the article. Sometimes more than one at once.
On the bright side, it finally caused me to get off my duff and map the mute and volume keys into X.
Because DragonFly defaults to public key only operation. No passworded access is allowed unless the user explicitly enables it, and we've recommended against enabling it for years now.
Just in case you didn't know, SATA and SAS use the same physical interface on the drive side. For systems with a small number of drives there isn't a whole lot of difference. The main issue comes down to how fan-out is handled when a large number of drives are available but the driver is simply so that vendors can pump up the price for the controllers and drives (double, triple, etc for basically the same hardware). The SATA protocol was intentionally hobbled in order to not compete with the SAS protocol. However, for a small number of drives, performance will basically be the same and the cost difference has driven lots of vendors to simply support both and use point-to-point links instead of fan-out anyway.
Sure, but having the bitcoin sitting in the bitcoin wallet doing nothing makes it kinda worthless, yah? The whole idea is to use it for commerce, at which point you are vulnerable to all sorts of scams and theft that you would normally be protected from.
Then there's liquidity. Most transactions are off-block-chain (as in one block-chain transaction per every ~400 or so off-block-chain transactions). They have to be, because putting a transaction on the block-chain takes too long. This means that you must inherently hold a balance, in bitcoin, with a third party, if you actually want to be able to use your bitcoin for general commerce. There are currently no protections whatsoever against that balance.
And then of course there's the volatility of the buying power of bitcoin itself. It's one of the most unstable and volatile currencies in existence.
That said it is better than nothing and certainly better vs certain emerging market currencies undergoing hyper-inflation.
But it isn't better than the dollar or any western currency and never will be.
This isn't correct. Banks can only lend out what they have. They can't manufacture leverage out of thin air. Leverage is a function of being lent money, not of lending out money.
The correct example is that the bank receives $1,000 in deposits from Alice and is allowed to lend out $900 of that. However, this means that the bank only has $100 cash on-hand so it cannot return Alice's $1,000, at least not immediately.
This does not mean that banks do not employ leverage, banks do borrow money, typically in the form of a preferred stock issuance. Just that they basically aren't allowed to in the example you gave. This is all laid out in bank financials. for example, for 2014 Wells Fargo had assets of $1.7 trillion and loans of $863 billion. The Deposit base is around $1.1 trillion.
So, $863 billion in loans on a deposit base of $1.1 trillion.
The mortgage crisis created a situation where loan losses exceeded the regulatory pad for many banks, and in several cases made them effectively insolvent. The Fed provided liquidity temporarily to give the banks time to become profitable again in order to be able to get back into compliance. Which most did. Most of those that did not, such as Washington Mutual, were either forced to be sold (at the beginning) or became desirable assets sold to other banks who were able to take over the deposit base without incurring losses to depositors. Most of the FDIC's losses (since recovered) occurred with smaller banks who had gone so deep into the red that they could not recover even with the extra few years the Fed gave them to become profitable again.
That's the reality. You don't have to like it, but people who deeply believe in bad information tend to wind up unhappy their entire lives when it turns out not to be true, over and over again. There's been a lot of that, too.
For renters it is pushing out people with lower incomes. Not everyone (due to rent control in areas), but still quite a lot of people are getting pushed out I think.
For existing lower-income homeowners it creates an opportunity to get a really good price for their home and then move to cheaper environs. (aka Gentrification).
The remaining pre-existing homeowners are not necessarily going anywhere. Prop 13 means that their property taxes are not changing radically and living costs are otherwise on a less steep ramp.
Gentrification is a two-edged sword, for sure, but I'm not sure that anything can really be done about it. The people protesting the changing nature of their neighborhoods are in the same economic class as many of the people selling and moving away. A person from group A can't really force a person from group B to not sell their home.
Blame posix for making all the goddamn pthread *_timedlock() calls take an absolute real time instead of a monotonic clock.
In anycase, I'm not even going to bother doing anything fancy. I'll let the system suddenly be one second off and then correct itself over the next hour. I'm certainly not going to do something stupid like letting the seconds field increment to 60. Having the ntp base time even go through these corrections is already dumb enough. Base time should be some absolute measure and leap seconds should just be adjusted after the fact in a manner similar to timezones.
The only TRIM use I recommend is running on it on an entire partition, e.g. like the swap partition, at boot, or before initializing a new filesystem. And that's it. It's an EXTREMELY dangerous command which results in non-deterministic operation. Not only do SSDs have bugs in handling TRIM, but filesystem implementations almost certainly also have ordering and concurrency bugs in handling TRIM. It's the least well-tested part of the firmware and the least well-tested part of the filesystem implementation. And due to cache effects, it's almost impossible to test it in a deterministic manner.
You can get close to the same performance and life out of your SSD without using TRIM by doing two simple things. First, use a filesystem with at least a 4KB block size so the SSD doesn't have to write-combine stuff on 512-byte boundaries. Second, simply leave a part of the SSD unused. 5% is plenty. In fact, if you have swap space configured on your SSD, that's usually enough on its own (since swap is not usually filled up during normal operation), as long as you TRIM it on boot.
I mean, come on... just when the graphics performance starts to get good, people all want bigger displays which halves the performance and then want to go even BIGGER and halve it again.
My perfectly good Sandybridge i7 can't drive this shit. Time to rotate in another workstation. Again.
I'm going to guess that he didn't file a gift tax return with the IRS for the millions he gave to person X. In which case he's up for tax evasion.
There's a certain degree of paranoia involved here as well. But this law isn't even the most onerous in the U.S. The worst one is the police confiscation laws that were originally intended to be anti-trafficking tools but now tend to be abused rather badly.
I think currently demonstrated ship-mountable railguns can emit a 7+ pound projectile at Mach 7. More to the point, these can be kinetic projectiles, meaning no explosives required, and there's more room for other things like, oh guidance systems.
Laser guns, meh. Limited to line-of-sight. Railguns on the other-hand are a whole 'nother ball of wax. Designs for Navy vessels now have to focus more and more on supplying power (as in electricity).
No, its a stupid recommendation. Spinning rust doesn't last very long on a shelf. It will rapidly go bad mechanically if you keep switching between shelf and active. SSDs are far superior and data retention is going to remain very high until they really dig into their durability. If you still care, there's no reason why you can't just leave them disconnected from a computer but still powered... they eat no real current compared to a hard drive. SSD-based data retention should be 30+ years if left powered... impossible to test as yet:-)... but no reason why not.
However, for backup purposes there is still an issue of cost. Using SSDs for bulk backup storage can be expensive... it wouldn't matter for a big business so much but cost can be a big issue for individual users.
SSDs don't go bad the way HDDs do. With a HDD maximum reasonably-safe life is 3 years whether powered or not (and swapping between powered and shelf will radically reduce its durability). With a SSD only durability really matters. A business can easily justify buying the required SSD storage in bulk with a marginal cost calculation, but it might be too big a hunk of change for an individual.
Personally speaking I still use HDDs for my backups, for reasons of cost, but I expect in the next few years that will change as SSD prices continue to drop. I just bumped up from 2TB x 3 (active, on-site backup, off-site backup) to 4TB x 3. My storage needs are going up more slowly than the technology is dropping in price. The two will meet in a few years and I'll be 100% SSDs. I'm already 100% SSDs for everything else. No point even contemplating a HDD any more except for bulk backup storage or software test rigs.
Actually, more and more SSDs today *DO* have power loss protection. Take it apart... if you see a bunch of capacitors on the mainboard all bunched together with no obvious purpose it's probably to keep power good long enough to finish writing out meta-data. Cheaper to use a lot of normal caps than to use thin-film high capacity caps.
This is not related to the SSD. If your cpus are pegged then it's something outside the disk driver. If it's system time it could be two things: (1) Either the compilers are getting into a system call loop of some sort or (2) The filesystem is doing something that is causing lock contention or other problems.
Well, it could be more than two things, but it is highly unlikely to be the SSD.
One thing I've noticed with fast storage devices is that sometimes housekeeping operations by filesystems can stall out the whole system because the housekeeping operations assume the disk I/O will block when, in many cases, the disk I/O completes instantly and essentially does not block, causing the kernel thread to eat more cpu than intended.
These tests explicitly state that the SSD is rewritten until it reaches its endurance rating before the retention test is done. At that point the flash in a consumer would not be expected to retain data unpowered for more than 1 year.
If you write your data to a fresh SSD once, multiply the number by at least 10.
This is the *mobile* i5, not the full blown desktop i5. It's basically the Broadwell successor to the Haswell 29xx series. 15W TDP or less. The BRIX runs 8W idle (not sleeping) and 20W at 100% cpu (all 4 threads full out). Intel is playing fast and loose with their naming schema for Broadwell.
All the older haswell-based boxes have dropped in price significantly. They make decent boxes too as long as you are not compute-heavy. E.G. the 2957U is 2-core, no hypthreading, 1.4 GHz, no-turbo, and no AESNI (so https and other crypto is slow). Whereas even the Broadwell i3-5200U is 2-core/4-thread, 2.2 GHz with Turbo to 2.7 GHz, and has AESNI.
I have an Acer C720P chromebook running DragonFly (BSD) with the 2955U in it, which is very close to the 2957U. I would call it decent for its purpose and it can certainly drive the chromebook's display fairly well. Firefox is not as snappy as I would like, though.
On the i5-5200U even unaccelerated video decoding can run full frame at full speed on my 1920x1050 monitor and firefox is quite snappy.
If I had to make a cost-concious decision on using the older Haswell based cpu and giving up some cpu power I would say that it would still be a reasonable choice *BUT* I would compensate at least a little by throwing in more ram (at least 4GB).
It's specced way too low to really be useful as a general computing device, and the form factor is 'weird' to say the least. It's too big to really be called a stick, and too small to be able to pack a decent cpu. There's plenty of space behind the monitor for a somewhat larger device in a better form factor. The stick is a play toy that you will become disappointed with very quickly (think the old 'netbook' concept Intel tried to push a few years ago... that's what the stick feels like).
Honestly, the 'compute stick' makes zero sense for a TV-mounted device. It is far better to just go with a chrome cast stick or an AppleTV for airplay and using a pad or cell in your hand to control it if you want to throw a display up on the TV. Otherwise you will be fumbling around with a horrible remote or you have to throw together a bluetooth keyboard (etc...) and it just won't be a fun or convenient experience.
My recommendation... don't bother with this gadget. Instead, spend a bit more money and get an Intel NUC or Gigabyte BRIX (both based on Broadwell). And get at least the i5 version, the lack of turbo in the i3 version is telling. e.g. i5-5200 based box or better. It will cost significantly more than the stick, but it packs a decent cpu, can take up to 16GB of ram (2x204pin SO-DIMM DDR3), and depending on the model might even have room for a 2.5" SSD or HDD in it. The broadwell i5-5200U makes for quite a reasonable compact workstation and boxes based on it will be almost universally dual-headed. Of course, whatever floats your boat but I would definitely say that the lowest-priced Intel NUC or Gigabyte BRIX that is haswell-based or broadwell-based is still going to be an order of magnitude better than the compute stick.
I have one of the Gigabyte GB-BXi5H-5200's myself ('H' version fits a normal 2.5" SSD or HDD) and packed 16GB of ram into it. It is dual-headed so I can drive two displays with it and the box is small enough to mount on the back of a monitor if you so desire (it even includes a mounting plate and most monitors, such as LG monitors, are ready to take it). And if mounting it on the back of a TV doesn't make sense, mount it on the back of a monitor instead or just let it float behind the monitor. It's a small box, after all, it won't get in the way of anything. 4-thread (2-core), 2.2 GHz turbo to 2.7 GHz. Dual-head. Decent.
That's isn't correct. The queue depth for a normal AHCI controller is 31 (assuming 1 tag is reserved for error handling). It only takes a queue depth of 2 or 3 for maximum linear throughput.
Also, most operating systems are doing read-ahead for the program. Even if a program is requesting data from a file in small 4K read() chunks, the OS itself is doing read-ahead with multiple tags and likely much larger 16K-64K chunks. That's assuming the data hasn't been cached in ram yet.
For writing, the OS is buffering the data and issuing the writes asynchronously so writing is not usually a bottleneck unless a vast amount of data is being shoved out.
Actually, large compiles use surprisingly little actual I/O. Run a large compile... e.g. a parallel buildworld or a large ports bulk build or something like that while observing physical disk I/O statistics. You'll realize very quickly that the compiles are not I/O constrained in the least.
'most' server demons are also not I/O constrained in the least. A web server can be IOPS-constrained when asked to load, e.g. tons of small icons or thumbnails. If managing a lot of video or audio streams a web server typically becomes network-constrained but the IOPS will be high enough to warrant at least a SATA SSD and not a HDD.
Random database accesses are I/O constrained if not well-cached in ram, which depends on the size of the database too, of course. Very large databases which cannot be well cached are the best suited for PCIe SSDs. Not a whole lot else.
I mean, why would anyone think images would load faster? The cpu is doing enough transformative work processing the image for display that the storage system only has to be able to keep ahead of it... which it can do trivially at 600 MBytes/sec if the data is not otherwise cached.
Did the author think that the OS wouldn't request the data from storage until the program actually asked for it? Of course the OS is doing read-ahead.
And programs aren't going to load much faster either, dynamic linking overhead puts a cap on it and the program is going to be cached in ram indefinitely after the first load anyway.
These PCIe SSDs are useful only in a few special mostly server-oriented cases. That said, it doesn't actually cost any more to have a direct PCIe interface verses a SATA interface so I these things are here to stay. Personally though I prefer the far more portable SATA SSDs.
Author must not know the difference between the real the rebrand. I would never buy Kingston anything. They just slap random components into those boards. There are hundreds of rebranders in the SSD space but only a handful of real companies. Kingston isn't one of them.
Slashdot Mirror
We finally get video and sound working properly and it's just been driving me BATTY when I have 30 firefox tabs open and can't figure out which one is making all the noise.
My absolute favorite is actually when a video site has video ads on the side bars that play over the video in the article. Sometimes more than one at once.
On the bright side, it finally caused me to get off my duff and map the mute and volume keys into X.
-Matt
Because DragonFly defaults to public key only operation. No passworded access is allowed unless the user explicitly enables it, and we've recommended against enabling it for years now.
-Matt
Just in case you didn't know, SATA and SAS use the same physical interface on the drive side. For systems with a small number of drives there isn't a whole lot of difference. The main issue comes down to how fan-out is handled when a large number of drives are available but the driver is simply so that vendors can pump up the price for the controllers and drives (double, triple, etc for basically the same hardware). The SATA protocol was intentionally hobbled in order to not compete with the SAS protocol. However, for a small number of drives, performance will basically be the same and the cost difference has driven lots of vendors to simply support both and use point-to-point links instead of fan-out anyway.
-Matt
Sure, but having the bitcoin sitting in the bitcoin wallet doing nothing makes it kinda worthless, yah? The whole idea is to use it for commerce, at which point you are vulnerable to all sorts of scams and theft that you would normally be protected from.
Then there's liquidity. Most transactions are off-block-chain (as in one block-chain transaction per every ~400 or so off-block-chain transactions). They have to be, because putting a transaction on the block-chain takes too long. This means that you must inherently hold a balance, in bitcoin, with a third party, if you actually want to be able to use your bitcoin for general commerce. There are currently no protections whatsoever against that balance.
And then of course there's the volatility of the buying power of bitcoin itself. It's one of the most unstable and volatile currencies in existence.
That said it is better than nothing and certainly better vs certain emerging market currencies undergoing hyper-inflation.
But it isn't better than the dollar or any western currency and never will be.
-Matt
This isn't correct. Banks can only lend out what they have. They can't manufacture leverage out of thin air. Leverage is a function of being lent money, not of lending out money.
The correct example is that the bank receives $1,000 in deposits from Alice and is allowed to lend out $900 of that. However, this means that the bank only has $100 cash on-hand so it cannot return Alice's $1,000, at least not immediately.
This does not mean that banks do not employ leverage, banks do borrow money, typically in the form of a preferred stock issuance. Just that they basically aren't allowed to in the example you gave. This is all laid out in bank financials. for example, for 2014 Wells Fargo had assets of $1.7 trillion and loans of $863 billion. The Deposit base is around $1.1 trillion.
So, $863 billion in loans on a deposit base of $1.1 trillion.
The mortgage crisis created a situation where loan losses exceeded the regulatory pad for many banks, and in several cases made them effectively insolvent. The Fed provided liquidity temporarily to give the banks time to become profitable again in order to be able to get back into compliance. Which most did. Most of those that did not, such as Washington Mutual, were either forced to be sold (at the beginning) or became desirable assets sold to other banks who were able to take over the deposit base without incurring losses to depositors. Most of the FDIC's losses (since recovered) occurred with smaller banks who had gone so deep into the red that they could not recover even with the extra few years the Fed gave them to become profitable again.
That's the reality. You don't have to like it, but people who deeply believe in bad information tend to wind up unhappy their entire lives when it turns out not to be true, over and over again. There's been a lot of that, too.
-Matt
For renters it is pushing out people with lower incomes. Not everyone (due to rent control in areas), but still quite a lot of people are getting pushed out I think.
For existing lower-income homeowners it creates an opportunity to get a really good price for their home and then move to cheaper environs. (aka Gentrification).
The remaining pre-existing homeowners are not necessarily going anywhere. Prop 13 means that their property taxes are not changing radically and living costs are otherwise on a less steep ramp.
Gentrification is a two-edged sword, for sure, but I'm not sure that anything can really be done about it. The people protesting the changing nature of their neighborhoods are in the same economic class as many of the people selling and moving away. A person from group A can't really force a person from group B to not sell their home.
-Matt
Blame posix for making all the goddamn pthread *_timedlock() calls take an absolute real time instead of a monotonic clock.
In anycase, I'm not even going to bother doing anything fancy. I'll let the system suddenly be one second off and then correct itself over the next hour. I'm certainly not going to do something stupid like letting the seconds field increment to 60. Having the ntp base time even go through these corrections is already dumb enough. Base time should be some absolute measure and leap seconds should just be adjusted after the fact in a manner similar to timezones.
-Matt
The only TRIM use I recommend is running on it on an entire partition, e.g. like the swap partition, at boot, or before initializing a new filesystem. And that's it. It's an EXTREMELY dangerous command which results in non-deterministic operation. Not only do SSDs have bugs in handling TRIM, but filesystem implementations almost certainly also have ordering and concurrency bugs in handling TRIM. It's the least well-tested part of the firmware and the least well-tested part of the filesystem implementation. And due to cache effects, it's almost impossible to test it in a deterministic manner.
You can get close to the same performance and life out of your SSD without using TRIM by doing two simple things. First, use a filesystem with at least a 4KB block size so the SSD doesn't have to write-combine stuff on 512-byte boundaries. Second, simply leave a part of the SSD unused. 5% is plenty. In fact, if you have swap space configured on your SSD, that's usually enough on its own (since swap is not usually filled up during normal operation), as long as you TRIM it on boot.
-Matt
I mean, come on... just when the graphics performance starts to get good, people all want bigger displays which halves the performance and then want to go even BIGGER and halve it again.
My perfectly good Sandybridge i7 can't drive this shit. Time to rotate in another workstation. Again.
Grumble.
-Matt
I'm going to guess that he didn't file a gift tax return with the IRS for the millions he gave to person X. In which case he's up for tax evasion.
There's a certain degree of paranoia involved here as well. But this law isn't even the most onerous in the U.S. The worst one is the police confiscation laws that were originally intended to be anti-trafficking tools but now tend to be abused rather badly.
http://www.npr.org/sections/th...
-Matt
I think currently demonstrated ship-mountable railguns can emit a 7+ pound projectile at Mach 7. More to the point, these can be kinetic projectiles, meaning no explosives required, and there's more room for other things like, oh guidance systems.
Good luck evading that.
-Matt
Laser guns, meh. Limited to line-of-sight. Railguns on the other-hand are a whole 'nother ball of wax. Designs for Navy vessels now have to focus more and more on supplying power (as in electricity).
-Matt
"Heartbeat monitor with a deadman's switch which blows away all my encryption keys."
ok... Maybe not.
"Car keys, house key, lead-line isotope container for when I need a distraction."
Hmm. Let me redact that.
"Car keys, house key, LED flash light, tag with 2D barcode with a virus URL in case someone is too curious."
There. That sounds reasonably sane.
-Matt
No, its a stupid recommendation. Spinning rust doesn't last very long on a shelf. It will rapidly go bad mechanically if you keep switching between shelf and active. SSDs are far superior and data retention is going to remain very high until they really dig into their durability. If you still care, there's no reason why you can't just leave them disconnected from a computer but still powered... they eat no real current compared to a hard drive. SSD-based data retention should be 30+ years if left powered... impossible to test as yet :-)... but no reason why not.
However, for backup purposes there is still an issue of cost. Using SSDs for bulk backup storage can be expensive... it wouldn't matter for a big business so much but cost can be a big issue for individual users.
SSDs don't go bad the way HDDs do. With a HDD maximum reasonably-safe life is 3 years whether powered or not (and swapping between powered and shelf will radically reduce its durability). With a SSD only durability really matters. A business can easily justify buying the required SSD storage in bulk with a marginal cost calculation, but it might be too big a hunk of change for an individual.
Personally speaking I still use HDDs for my backups, for reasons of cost, but I expect in the next few years that will change as SSD prices continue to drop. I just bumped up from 2TB x 3 (active, on-site backup, off-site backup) to 4TB x 3. My storage needs are going up more slowly than the technology is dropping in price. The two will meet in a few years and I'll be 100% SSDs. I'm already 100% SSDs for everything else. No point even contemplating a HDD any more except for bulk backup storage or software test rigs.
-Matt
Actually, more and more SSDs today *DO* have power loss protection. Take it apart... if you see a bunch of capacitors on the mainboard all bunched together with no obvious purpose it's probably to keep power good long enough to finish writing out meta-data. Cheaper to use a lot of normal caps than to use thin-film high capacity caps.
-Matt
This is not related to the SSD. If your cpus are pegged then it's something outside the disk driver. If it's system time it could be two things: (1) Either the compilers are getting into a system call loop of some sort or (2) The filesystem is doing something that is causing lock contention or other problems.
Well, it could be more than two things, but it is highly unlikely to be the SSD.
One thing I've noticed with fast storage devices is that sometimes housekeeping operations by filesystems can stall out the whole system because the housekeeping operations assume the disk I/O will block when, in many cases, the disk I/O completes instantly and essentially does not block, causing the kernel thread to eat more cpu than intended.
-Matt
These tests explicitly state that the SSD is rewritten until it reaches its endurance rating before the retention test is done. At that point the flash in a consumer would not be expected to retain data unpowered for more than 1 year.
If you write your data to a fresh SSD once, multiply the number by at least 10.
-Matt
This is the *mobile* i5, not the full blown desktop i5. It's basically the Broadwell successor to the Haswell 29xx series. 15W TDP or less. The BRIX runs 8W idle (not sleeping) and 20W at 100% cpu (all 4 threads full out). Intel is playing fast and loose with their naming schema for Broadwell.
-Matt
All the older haswell-based boxes have dropped in price significantly. They make decent boxes too as long as you are not compute-heavy. E.G. the 2957U is 2-core, no hypthreading, 1.4 GHz, no-turbo, and no AESNI (so https and other crypto is slow). Whereas even the Broadwell i3-5200U is 2-core/4-thread, 2.2 GHz with Turbo to 2.7 GHz, and has AESNI.
I have an Acer C720P chromebook running DragonFly (BSD) with the 2955U in it, which is very close to the 2957U. I would call it decent for its purpose and it can certainly drive the chromebook's display fairly well. Firefox is not as snappy as I would like, though.
On the i5-5200U even unaccelerated video decoding can run full frame at full speed on my 1920x1050 monitor and firefox is quite snappy.
If I had to make a cost-concious decision on using the older Haswell based cpu and giving up some cpu power I would say that it would still be a reasonable choice *BUT* I would compensate at least a little by throwing in more ram (at least 4GB).
-Matt
It's specced way too low to really be useful as a general computing device, and the form factor is 'weird' to say the least. It's too big to really be called a stick, and too small to be able to pack a decent cpu. There's plenty of space behind the monitor for a somewhat larger device in a better form factor. The stick is a play toy that you will become disappointed with very quickly (think the old 'netbook' concept Intel tried to push a few years ago... that's what the stick feels like).
Honestly, the 'compute stick' makes zero sense for a TV-mounted device. It is far better to just go with a chrome cast stick or an AppleTV for airplay and using a pad or cell in your hand to control it if you want to throw a display up on the TV. Otherwise you will be fumbling around with a horrible remote or you have to throw together a bluetooth keyboard (etc...) and it just won't be a fun or convenient experience.
My recommendation... don't bother with this gadget. Instead, spend a bit more money and get an Intel NUC or Gigabyte BRIX (both based on Broadwell). And get at least the i5 version, the lack of turbo in the i3 version is telling. e.g. i5-5200 based box or better. It will cost significantly more than the stick, but it packs a decent cpu, can take up to 16GB of ram (2x204pin SO-DIMM DDR3), and depending on the model might even have room for a 2.5" SSD or HDD in it. The broadwell i5-5200U makes for quite a reasonable compact workstation and boxes based on it will be almost universally dual-headed. Of course, whatever floats your boat but I would definitely say that the lowest-priced Intel NUC or Gigabyte BRIX that is haswell-based or broadwell-based is still going to be an order of magnitude better than the compute stick.
I have one of the Gigabyte GB-BXi5H-5200's myself ('H' version fits a normal 2.5" SSD or HDD) and packed 16GB of ram into it. It is dual-headed so I can drive two displays with it and the box is small enough to mount on the back of a monitor if you so desire (it even includes a mounting plate and most monitors, such as LG monitors, are ready to take it). And if mounting it on the back of a TV doesn't make sense, mount it on the back of a monitor instead or just let it float behind the monitor. It's a small box, after all, it won't get in the way of anything. 4-thread (2-core), 2.2 GHz turbo to 2.7 GHz. Dual-head. Decent.
-Matt
Huh? This sounds like nonsense. Operating systems already cache frequently used data in ram.
-Matt
That's isn't correct. The queue depth for a normal AHCI controller is 31 (assuming 1 tag is reserved for error handling). It only takes a queue depth of 2 or 3 for maximum linear throughput.
Also, most operating systems are doing read-ahead for the program. Even if a program is requesting data from a file in small 4K read() chunks, the OS itself is doing read-ahead with multiple tags and likely much larger 16K-64K chunks. That's assuming the data hasn't been cached in ram yet.
For writing, the OS is buffering the data and issuing the writes asynchronously so writing is not usually a bottleneck unless a vast amount of data is being shoved out.
-Matt
Actually, large compiles use surprisingly little actual I/O. Run a large compile... e.g. a parallel buildworld or a large ports bulk build or something like that while observing physical disk I/O statistics. You'll realize very quickly that the compiles are not I/O constrained in the least.
'most' server demons are also not I/O constrained in the least. A web server can be IOPS-constrained when asked to load, e.g. tons of small icons or thumbnails. If managing a lot of video or audio streams a web server typically becomes network-constrained but the IOPS will be high enough to warrant at least a SATA SSD and not a HDD.
Random database accesses are I/O constrained if not well-cached in ram, which depends on the size of the database too, of course. Very large databases which cannot be well cached are the best suited for PCIe SSDs. Not a whole lot else.
-Matt
I mean, why would anyone think images would load faster? The cpu is doing enough transformative work processing the image for display that the storage system only has to be able to keep ahead of it... which it can do trivially at 600 MBytes/sec if the data is not otherwise cached.
Did the author think that the OS wouldn't request the data from storage until the program actually asked for it? Of course the OS is doing read-ahead.
And programs aren't going to load much faster either, dynamic linking overhead puts a cap on it and the program is going to be cached in ram indefinitely after the first load anyway.
These PCIe SSDs are useful only in a few special mostly server-oriented cases. That said, it doesn't actually cost any more to have a direct PCIe interface verses a SATA interface so I these things are here to stay. Personally though I prefer the far more portable SATA SSDs.
-Matt
Author must not know the difference between the real the rebrand. I would never buy Kingston anything. They just slap random components into those boards. There are hundreds of rebranders in the SSD space but only a handful of real companies. Kingston isn't one of them.
-Matt