I'm not sure if I understand the problem. If it is caching, shouldn't the OS write out the cache when it shuts down, and clear it before it starts using it on bootup?
The OS already has a buffer cache that does that in RAM.:-)
The point of the SSD cache, in large part, is that it's persistent across boots. "What I use today, I'm likely to use tomorrow." Repopulating the cache each time the computer boots would drop a large part of the benefit of having it in the first place.
Except flash is very slow to write, so slow that Android won't let you write to flash on the foreground thread.
There are different grades of flash. SD cards and USB sticks are bad. Actual SSD drives that you use as a substitute for HDDs write faster than HDDs.
On Windows writes are done async the call returns before the write has completed and it doesn't slow you down as a result.
...unless it's a synchronous write. Many programs explicitly issue sync() calls to flush the buffer cache to disk. This is necessary to get durability. I'm not positive, but I think that certain file system operations like creating a file, allocating or releasing blocks, and other things which change the actual metadata of the file system and get journaled are necessarily synchronous.
"While the Vertex 3 [pure SSD, no caching] is still a bit faster, you can't argue that Intel's SRT doesn't deliver most of the SSD experience at a fraction of the costâ"at least when it comes to individual application performance."
"Performance keeps going up. The maximized SRT system is now virtually indistinguishable from the standalone SSD system."
"I worried that Intel's SRT would only cache the most frequently used level and not improve performance across the board. I was wrong."
The story isn't entirely good -- after all, it's not a full-blown SSD -- but like I said, it's absolutely false to say that SSDs only help with boot time.
I've never seen anything real world other than a boot demo
Congrats on your ass-talking, considering that you just admitted that you have no information to support your claims.
The benchmarks I've seen treat the read times in isolation, but of course if its in RAM already, the read never happens, so the real world read time is zero and there's no much optimization possible on zero.
...except as I've repeatedly told you and you seem fond of ignoring, there are many situations where the data won't be in RAM but will be in a SSD cache.
You can absolutely install programs in other directories than/usr, using the dpkg package system.
Yes and no. dpkg is sort of up to it, but the ecosystem needs a lot of support to make it work.
For instance, let's say that we have a library and a program, and Program depends on Library. (For the moment, these are separate packages.) The user installs Library to a different location. How is Program going to find it? The conventional strategy would be to compile Program with Library's path, and it gets added to the rpath field inside Program's actual executable. A modification of this conventional strategy which would work with a more directory-based package manager would be to use patchelf or something to rewrite the executable's rpath entry to include Library's actual install directory. But where's it going to get that information? I guess you could have the post-install script look up the installation directory from the dpkg database, but again, it's inelegant and would have to be done independently for every package, as opposed to having direct support in the package manager. And as I describe below, I suspect that wouldn't work.
The dpkg package specifies where the files are to be installed. You can absolutely install programs in other directories than/usr, using the dpkg package system.
Like I said, I'm not very familiar with the dpkg-level of things. My understanding of your statements are that the package maintainer can choose the directory, but the only control over installation directory from the user's side that I see is --instdir.
And if this understanding is correct, --instdir is insufficient: dpkg will chroot to that directory to do the installation and run the configure scripts, but what if a dependency is installed outside of that root? The way that current packages are set up, I can't install both Program and Library to different directories.
If you want to use dpkg to install programs to a network drive, you can certainly do so. The filesystem makes no distinction between a network mounted directory and a local directory. It's all one big tree.
Oh, I was under no illusion that it would treat it differently; I was just mentioning the network drive situation to explain my use case a little bit more.
You will need to be root to install the dpkg package. Write access to the package database is only allowed as root.
Another place where dpkg falls short of my ideal package manager. Why is there a single centralized database when different users may have different software installed?
If the file is in RAM, then the cache on the HD adds nothing. I already pointed out the boot scenario is the only difference there, you're defining reboots as somehow not boots!? Your suspend data is not frequent data and thus not in the cache anyway.
I'm not talking about suspend data.
I'm talking about after the system boots, and I start Opera, or I start HL2. That data isn't going to be cached. It's not even going to be cached if it was in the buffer cache before shutting down.
(I use HL2 because it, and especially the episodes, benefit tremendously from being located on an SSD. The "loading" times are cut tremendously, which helps a lot with one of that series's big immersion breakers. (I am comparing HDD to full SSD -- not hybrid/cached -- but benchmarks for hybrid setups show a lot of the benefits.))
It's a bit of a moot point, since the long read is going into *RAM* anyway, so there's enough ram for it, even if there isn't enough flash.
First, that long read will take a lot longer to go from HDD -> RAM than from SSD -> RAM.
But mainly, you missed my point. If your working set (defined loosely) is more than RAM size, it won't all fit into RAM. If I cycle through a couple different data-heavy games then go back to the first one, that will no longer be in the buffer cache because it will have been flushed. It will, however, likely see a speed boost from part of it being in the SSD cache.
Writes are done in the background anyway. They don't slow down the user.
Lots of writes are synchronous, you know.
Heck, there's even a substantial difference on the Smart Response benchmarks (that's Intel's northbridge-based, hybrid-hardware/software SSD caching scheme) between using the SSD as a write-through and write-back cache.
Anyway, I'm not saying all workloads will benefit. But I've found that the SSD has helped, and many others (e.g. Linus) have said that going from a HDD to SSD is by far the most cost-effective upgrade for many people. Saying that it only helps boot times is just flat out wrong.
(especially for the use case that involves an OSX-like 'copy this special folder into a directory I have write privileges for' install operation, rather than a system-wide change, though system-wide cases would be doable as well)
Note that there's a big difference between these two cases. (The two cases are (1) allowing the administrator to delegate system-wide installation rights to a user and (2) users can unilaterally install programs to/home/me.) At least if you want to take the second case to it's "natural" conclusion.
In the case where the system-wide installation is being done, that's just a simple privilege delegation problem, and you're right it should be easy to solve.
However, in the second case, things become a lot dicier. Different users will have different stuff installed, so you need to split up the database of installed packages. Currently you can only have one version of a package installed at once with most package managers, and if you update it then the old one is replaced; with change (2), it becomes natural to allow multiple versions installed to separate directories, so now the package manager needs to be able to deal with that. If your packages aren't self-contained, then they need to know the path of their dependencies; since that path now can be anything, your package manager needs a way to instruct the packages that it's installing what those paths are.
Tons of morons who only know and understand Windows and OS X, and think things work the same way on Linux.
I like how you just assume that they don't understand that what they're doing is contrary to Unix orthodoxy. But Unix orthodoxy is just that -- it's the way things currently are. Yes people should understand why Unix does things the way that it does. But at the same time, no way is it the be-all, end-all of computing. The Unix orthodoxy also has a lot of problems, many of which are seldom acknowledged by people such as yourself. (For instance, I can link to a rant I've written about why I think the Linux command line is due for a major overhaul if you'd like an example of one such class of problems that I see.)
No, 24GB RAM is $60, not $200. I just bought 4GB sticks of DDR3 for 300 baht retail, = 6*$10 = $60.
Where the heck did you find that?
Newegg's cheapest price for 2x4GB is $53....if you have the RAM the HD with flash is cached in RAM regardless and the flash cache adds nothing.
Not true.
1) The SSD cache will persist through reboots. That helps not just boot time but also stuff that you do for the first time after booting. I keep my Windows computer hibernated when not using it, and see a noticeable speed boost from SSD.
2) I'm not sure if the hardware hybrid drives do this, but at least Intel's Smart Response claims to be intelligent about what it caches. For instance, if you do a long sequential read from the HDD, it won't cache the whole read, just the start. In some sense this makes the cache seem larger. I'm not sure if OS buffer caches do this, but I kind of doubt it because they are made for a separate purpose.
I remember checking it out and deciding it didn't do what I wanted. Looking at the page, I think it was the last con: "So unfortunately it will not help with the massive.gcf files in the steamapps folder itself (mostly Valve games such as Counter-Strike and the Half-Life series)."
So I've pretty much just done it manually. (If I were smart I'd use steammover for the things it works for and do other things manually, but I'm not.:-))
the only gain with these drives is on startup and then not by much
That's not quite fair. Assuming it's a write-through cache you could still see a significant write boost compared to just an SSD. And there's other data which would be beneficial to have fast access to but isn't in the OS buffer cache, for instance because you've recently turned the computer back on. For instance, I see substantially better load times in many games than I did with a HDD, even though I should have enough of a buffer cache. And while this isn't a fair comparison because I have a full SSD instead of hybrid, the benchmarks I've seen of other SSD caching solutions have looked reasonably good; from what I can tell, a lot of those improvements would translate over.
Then you don't want spinning platters in your laptop draining your battery, you want a full on SSD that just barely sips power with no speed loss.
What if you have need for a hefty amount of storage without paying through the nose? You can get a 1 TB hybrid laptop drive for much less than the cost of a full SSD that's a quarter of the size. Or a 500 GB hybrid for just a little bit more than a 128 GB SSD.
Obviously not everyone needs that space, but I certainly would if my main computer were a laptop.
For me, the differences are things like (1) better window managers, (2) better native shells (though I really like Powershell), (3) openness, and (4) a couple Linux-only apps. That's why I use Linux some of the time. Efficiency comes in... well, pretty far down the list.
At under $250 for a 256 Gig SSD, why would anyone buy a combination drive anymore?
Depending on what you do on your computer, space. For instance, I have well over 256 GB of data that would benefit substantially from SSD speeds. (For instance, games often see significantly decreased level loading times; particularly important with things like HL2 where the loads break the flow. My Steam directory alone is 132 GB.)
I don't churn through all of it regularly, but rather it'll be more like I use 20 GB for a few weeks, then switch to another 20 GB for another few weeks. This is the kind of usage that I suspect might actually benefit quite a bit from automatic caching.
I get good performance by manually copying around whatever game it is that I want to play at the moment, but deciding data should live on the HDD and what should be on the SSD is a bit of annoying work and I'm almost certainly not making the best decisions.
No; You can achieve that with a separate SSD and a mechanical drive; That's what most people are doing now anyway.
I have a separate SSD and HDD, but I also don't think that you're being entirely fair to the hybrid drives. You can set up software (bcache) or hybrid (Intel Smart Response) caching, but near as I can tell that will greatly hamper dual booting. You can keep the file systems separate (as I'm doing), but now you have to worry about manual adjustment of what data is on what drive where an automatic solution may well do better and would certainly be less work.
I'm not sure how the hybrid drive performance compares, but the Smart Response benchmarks I've seen were reasonably decent. If the hybrid drives are somewhat similar and if dual booting or something like it is important to you, it very well could be that a hybrid drive with hardware support offers the best tradeoffs.
IMO it's a problem either way. The Intel "Smart Response" stuff that they introduced as a chipset feature a year or two ago (you put a HDD and SSD in your computer and it will cache stuff on the SSD) works similar. A neat idea, but a non-starter for what I wanted. Why?
Even if it works fine in Windows and works fine in Linux, it may still not really work if you want to dual boot. If you want to be able to use the SSD cache in both operating systems, they have to be able to not step on each others toes. If you want to be able to read data from the other OS, it has to be able to understand the format the other is in. (Potentially this could be "doesn't have to do anything in particular" if you make it a write-through cache, but write-back caches might have more stuff. And you still need to understand the format to write if you have a write-through cache.)
Obviously not everyone needs dual booting, but not everyone needs Linux support either. It's a bit selfish to say that it's a problem if there is only support in Windows, but it's not a problem if there is support in both OSs but the support isn't compatible.:-)
The difference is that/etc is implemented using two of the most mature and well understood pieces of the system: a file system directory hierarchy and text files.
You're simplifying.
You can't just say "text files", because I can't write "Hey Apache, I want you to put password protection on the stuff in/var/html/secret" in a file and have it work. Instead, Linux config files take many different formats, from INI-style to XML to shell scripts to custom formats like the X11 config.
I can very easily turn around the argument as follows:
"The difference is that/etc is implemented using a bunch of inconsistent formats. The Windows registry, in contrast, is implemented using a consistent, reasonably simple, typed key-value hierarchical database."
And speaking of "rich access control"./etc has extremely robust access control via the filesystem. Access control that is well tested, well documented and well understood.
The equivalent of registry-style access control would be more like separate ACLs for each line of a file. To do that, oh, you have to write a special program like crontab which runs with setuid (I guess that's what it does?) to edit the file but takes instructions from something else.
Useful? No clue, I don't do enterprise stuff. But from a pure objective level, the Windows registry offers a significantly more expressive set of security settings.
another thing windows devs don't get is shared libraries (DLLs in windows terminology). Why does every single app have to install their own copy of the MS C++ libraries? or.net? or nvidia physx? and numerous other common library packages? these things are supposed to be shared resources provided and kept up-to-date by the operating system, not bundled with every app that uses them.
They are... sort of. Take the MSVC runtime. That's not maintained or installed necessarily by the OS for (some good, some mediocre) reasons which I'll explain in a second, but I'm 95% sure that it's shared between programs in the sense that when you see an program installer that spawns off the MSVC runtime installer, the latter will either be (1) installing a new version of the MSVC runtime or (2) discovering that it's already present and doing nothing. The runtime installs to a shared location. (Look at msvc*.dll in windows\system32.) So the runtime installer has to be bundled with individual programs for the upcoming reasons, but it's not wasting disk space by installing duplicate copies (subject to the caveat below) or wasting memory by loading the same thing from different hard drive locations at different time.
So why does it do this? Well, a couple reasons, I think. (I'm speculating here, but I consider them educated guesses.) First is the mediocre reason: there's no package manager. This leads to the "well, you have to ship the runtime installer with each program."
Second is the pretty-good reason: compatibility and correctness. You can definitely have multiple major versions (e.g. the runtime associated with VS2008 and 2010) installed simultaneously, and I think you might be able to have multiple patch versions of the same library installed simultaneously. I think the former is true in Linux too (libfoo.so.1.0.0 vs libfoo.so.2.0.0, though I thought those only show up for -devel packages... hmmm, not sure), but the latter isn't so much. It may well be that Program A installs version 1.0.0 and Program B installs version 1.0.1239, where on Linux the latter would likely be packaged to upgrade the former. (This is the caveat to my "no wasted space" claim above.)
Why is that good? Well, why did the library change? Bug fix? Well, MS usually will bend over backwards to maintain compatibility, which has often meant bug-for-bug compatibility with old programs, at least as a shim. If you take the Linux approach, then programs which rely on the old behavior of the buggy code will break. This is sometimes good (e.g. bad security-related fixes), but is often not. Or it doesn't have to be a bug fix, it could just be some behavior change within the specification. By keeping multiple versions around, the Windows approach keeps the individual programs happier.
How you weight these various advantages and disadvantages is up to you. I'm not really trying to argue that the Windows approach is better, just explain why it is as it is and give a fair description of what goes on.
Crap, shoulda previewed. Sorry for the formatting. Fixed version:
Then you would end up with a massive PATH variable...
First: that's only one solution. For example, I have (issues file system query) probably three or four thousand different packages available to me right now, all installed into their own directory. (This counts multiple versions separately. As a disclamer, some of those packages are very very old and won't even run on this system as the library dependencies aren't present or they are only built for another architecture, and most of the others are obsolete and there's little reason to use them. Point being: I have access to tons of packages.) My $PATH has 21 entries, including some redundancies.
The first step to reconciling these facts is basically what you suggest later in your post: that there are multiple directories with symlinks. For instance, ~/bin is in my $PATH, and it has a few dozen symlinks to some of those packages.) But doing this or what you said ("one possibility might involve putting symlinks in/usr/bin to program files into another directory where different versions of the program can be stored") still requires a package manager which can install to a different location, which is not really supported by the Apt toolchain.
Second: just because you have a package available doesn't mean you need it in your $PATH. I have a ton of different GCC versions available, and I use three or four with some regularity. (I use even more of them infrequently.) But I don't necessarily need, say, GCC 4.5 in my $PATH. If I want 4.5 explicitly, I can always run/path/to/gcc-4.5/bin/gcc.
Third: you have to remember who Ubuntu is aimed at. It's aimed at casual users. Casual users don't even care about $PATH in the first place, because they don't start things from the command line. They just hit the windows key or whatever they do to bring up the launcher, choose what program they want to run, and click it.
...and also does not follow the time honored Unix tradition which needs to be respected.
They need to be respected, even if it has significant problems in some environments and fatal problems in others (e.g. mine)?
Unix had a ton of really great ideas. But many of them have run their course. You can't progress if you say you can't change stuff.
Then you would end up with a massive PATH variable...
First: that's only one solution. For example, I have (issues file system query) probably three or four thousand different packages available to me right now, all installed into their own directory. (This counts multiple versions separately. As a disclamer, some of those packages are very very old and won't even run on this system as the library dependencies aren't present or they are only built for another architecture, and most of the others are obsolete and there's little reason to use them. Point being: I have access to tons of packages.) My $PATH has 21 entries, including some redundancies.
The first step to reconciling these facts is basically what you suggest later in your post: that there are multiple directories with symlinks. For instance, ~/bin is in my $PATH, and it has a few dozen symlinks to some of those packages.) But doing this or what you said ("one possibility might involve putting symlinks in/usr/bin to program files into another directory where different versions of the program can be stored") still requires a package manager which can install to a different location, which is not really supported by the Apt toolchain.
Second: just because you have a package available doesn't mean you need it in your $PATH. I have a ton of different GCC versions available, and I use three or four with some regularity. (I use even more of them infrequently.) But I don't necessarily need, say, GCC 4.5 in my $PATH. If I want 4.5 explicitly, I can always run/path/to/gcc-4.5/bin/gcc.
Third: you have to remember who Ubuntu is aimed at. It's aimed at casual users. Casual users don't even care about $PATH in the first place, because they don't start things from the command line. They just hit the windows key or whatever they do to bring up the launcher, choose what program they want to run, and click it....and also does not follow the time honored Unix tradition which needs to be respected.
They need to be respected, even if it has significant problems in some environments and fatal problems in others (e.g. mine)?
We need it because while current packaging systems are great for central control, they are bad for actually letting users contribute.
One more: e) Most current packaging systems don't let you pick an installation directory. (Many programs have directories set in stone when you compile them.)
This is one that has affected me, because in the environment I work in, we have standard stuff installed locally but a lot of more esoteric software as well as more current versions of software installed to network drives. (For instance, we run RHEL6 which comes packaged with Python 2.6, but I almost always use Python 2.7 off of the network. Or we have Clementine available for use only over the network.) But the way existing package managers work means that we can't really use them, which means that if I want to make something new available over the network, I have to go and chase down its dependencies myself and then compile everything.
3) Centralized control over what software is installed suddenly becomes difficult
I would argue that point for the most part. From some vantage point, it's already difficult to have centralized control over what's installed. After all, I can still do what I described above to install software, without the support of the package manager. It's just a pain. Or even if you switch to a better package manager that allows users to have control over what gets installed, you can still block that as an administrator by setting noexec on the drives.
I don't want to get into whether you could use DPKG packages for what they want to do; that's beyond my scope of knowledge. However, what I can tell you is that for some tasks, apt-get just flat out doesn't work.
In particular, if you want to install programs to something other than/usr (for instance, you want to install to a network drive, or without root), then the mainstream package managers just flat out don't work.
$600 is the full retail price for Photoshop CS6, not the upgrade price. The upgrade price is somewhere around $250â"300, depending on whether you have the regular or extended edition, IIRC. Maybe $350. I upgraded a few months ago, so that's from memory.
So I did a little bit of searching (admittedly right after I posted, which is when I thought of it), and I still stand by my statement mostly. From what I can tell, there is no upgrade to CS6 except from CS5. This means that if you're paying the upgrade price, you're probably upgrading every version or nearly every version anyway. So under that policy, if you're comparing the price vs someone who only upgrades every few versions, you've got to look at the full price anyway.
Now, this is a new thing with CS6 (one thing I saw made it sound like it) and older versions had a more liberal upgrade policy, but it is what Adobe was using before creative cloud was announced.
o in effect, if you don't keep paying, you lose access to your local files. Sure, you still technically have the files, but they're as useful as a condom in a nunnery.
Those condoms in a nunnery will still be useful if you later go to a brothel. [I can't believe I just typed that sentence.:-)]
Actually more clarifications now that I've looked at the FAQ a bit:
You're forced to pay for access during months when you don't use the software - or you lose your data Not only is this wrong for the reason I gave before (you still can use local files), but you have 90 days after cancelling your membership to still access your files. (After that, yes, you'll lose some work. Though there's still a free 2 GB you'll have access to.)
You need to be internet connected to the internet for it to work You need a reasonably fast internet connection for it to work You need a reasonably reliable internet connection for it to work
My once a month statement was low. The FAQ is slightly confusing, but it sounds like it will work for 6 months without an activation (just bug you once a month).
That said, the conclusion isn't wrong, only the numbers.
Sort of. That depends on your situation. For instance, as you acknowledge, your conclusion depends on the assumption that you don't upgrade each new version. Someone who does would look at the correct numbers and go "yes, this makes sense". (A different conclusion!)
And even if it doesn't reverse the cost figuring entirely, it may be the cost difference is low enough that the value is still in favor of paying a little bit more. It does no one any good to use incorrect numbers.
Buys an upgrade about every 6 years (3 major versions) at $250â"300, or to $42â"50 per year.
Where are you getting that number? Amazon's Photoshop CS6 price is over $600. Even the student/teacher version is over $300. That alone would take your 6x cost increase to 3x.
But the biggest problem I have with this arrangement is that it leaves me completely dependent upon Adobe's good graces. At any time, they can decide to crank the price to $100 per month, and I can either pay it or I lose access to all my files.
Don't think of this as Adobe implementing a Photoshop analogy to Google Docs; this isn't PS running in the browser. Instead, it's a subscription-based version of what people already have that just checks in once a month (and forces in after 6 months). You'll still be able to edit local files.
Slashdot Mirror
The OS already has a buffer cache that does that in RAM. :-)
The point of the SSD cache, in large part, is that it's persistent across boots. "What I use today, I'm likely to use tomorrow." Repopulating the cache each time the computer boots would drop a large part of the benefit of having it in the first place.
There are different grades of flash. SD cards and USB sticks are bad. Actual SSD drives that you use as a substitute for HDDs write faster than HDDs.
Anandtech.
"While the Vertex 3 [pure SSD, no caching] is still a bit faster, you can't argue that Intel's SRT doesn't deliver most of the SSD experience at a fraction of the costâ"at least when it comes to individual application performance."
"Performance keeps going up. The maximized SRT system is now virtually indistinguishable from the standalone SSD system."
"I worried that Intel's SRT would only cache the most frequently used level and not improve performance across the board. I was wrong."
The story isn't entirely good -- after all, it's not a full-blown SSD -- but like I said, it's absolutely false to say that SSDs only help with boot time.
Congrats on your ass-talking, considering that you just admitted that you have no information to support your claims.
Yes and no. dpkg is sort of up to it, but the ecosystem needs a lot of support to make it work.
For instance, let's say that we have a library and a program, and Program depends on Library. (For the moment, these are separate packages.) The user installs Library to a different location. How is Program going to find it? The conventional strategy would be to compile Program with Library's path, and it gets added to the rpath field inside Program's actual executable. A modification of this conventional strategy which would work with a more directory-based package manager would be to use patchelf or something to rewrite the executable's rpath entry to include Library's actual install directory. But where's it going to get that information? I guess you could have the post-install script look up the installation directory from the dpkg database, but again, it's inelegant and would have to be done independently for every package, as opposed to having direct support in the package manager. And as I describe below, I suspect that wouldn't work.
Like I said, I'm not very familiar with the dpkg-level of things. My understanding of your statements are that the package maintainer can choose the directory, but the only control over installation directory from the user's side that I see is --instdir.
And if this understanding is correct, --instdir is insufficient: dpkg will chroot to that directory to do the installation and run the configure scripts, but what if a dependency is installed outside of that root? The way that current packages are set up, I can't install both Program and Library to different directories.
Oh, I was under no illusion that it would treat it differently; I was just mentioning the network drive situation to explain my use case a little bit more.
Another place where dpkg falls short of my ideal package manager. Why is there a single centralized database when different users may have different software installed?
I'm not talking about suspend data.
I'm talking about after the system boots, and I start Opera, or I start HL2. That data isn't going to be cached. It's not even going to be cached if it was in the buffer cache before shutting down.
(I use HL2 because it, and especially the episodes, benefit tremendously from being located on an SSD. The "loading" times are cut tremendously, which helps a lot with one of that series's big immersion breakers. (I am comparing HDD to full SSD -- not hybrid/cached -- but benchmarks for hybrid setups show a lot of the benefits.))
First, that long read will take a lot longer to go from HDD -> RAM than from SSD -> RAM.
But mainly, you missed my point. If your working set (defined loosely) is more than RAM size, it won't all fit into RAM. If I cycle through a couple different data-heavy games then go back to the first one, that will no longer be in the buffer cache because it will have been flushed. It will, however, likely see a speed boost from part of it being in the SSD cache.
Lots of writes are synchronous, you know.
Heck, there's even a substantial difference on the Smart Response benchmarks (that's Intel's northbridge-based, hybrid-hardware/software SSD caching scheme) between using the SSD as a write-through and write-back cache.
Anyway, I'm not saying all workloads will benefit. But I've found that the SSD has helped, and many others (e.g. Linus) have said that going from a HDD to SSD is by far the most cost-effective upgrade for many people. Saying that it only helps boot times is just flat out wrong.
(especially for the use case that involves an OSX-like 'copy this special folder into a directory I have write privileges for' install operation, rather than a system-wide change, though system-wide cases would be doable as well)
Note that there's a big difference between these two cases. (The two cases are (1) allowing the administrator to delegate system-wide installation rights to a user and (2) users can unilaterally install programs to /home/me.) At least if you want to take the second case to it's "natural" conclusion.
In the case where the system-wide installation is being done, that's just a simple privilege delegation problem, and you're right it should be easy to solve.
However, in the second case, things become a lot dicier. Different users will have different stuff installed, so you need to split up the database of installed packages. Currently you can only have one version of a package installed at once with most package managers, and if you update it then the old one is replaced; with change (2), it becomes natural to allow multiple versions installed to separate directories, so now the package manager needs to be able to deal with that. If your packages aren't self-contained, then they need to know the path of their dependencies; since that path now can be anything, your package manager needs a way to instruct the packages that it's installing what those paths are.
Tons of morons who only know and understand Windows and OS X, and think things work the same way on Linux.
I like how you just assume that they don't understand that what they're doing is contrary to Unix orthodoxy. But Unix orthodoxy is just that -- it's the way things currently are. Yes people should understand why Unix does things the way that it does. But at the same time, no way is it the be-all, end-all of computing. The Unix orthodoxy also has a lot of problems, many of which are seldom acknowledged by people such as yourself. (For instance, I can link to a rant I've written about why I think the Linux command line is due for a major overhaul if you'd like an example of one such class of problems that I see.)
No, 24GB RAM is $60, not $200. I just bought 4GB sticks of DDR3 for 300 baht retail, = 6*$10 = $60.
Where the heck did you find that?
Newegg's cheapest price for 2x4GB is $53. ...if you have the RAM the HD with flash is cached in RAM regardless and the flash cache adds nothing.
Not true.
1) The SSD cache will persist through reboots. That helps not just boot time but also stuff that you do for the first time after booting. I keep my Windows computer hibernated when not using it, and see a noticeable speed boost from SSD.
2) I'm not sure if the hardware hybrid drives do this, but at least Intel's Smart Response claims to be intelligent about what it caches. For instance, if you do a long sequential read from the HDD, it won't cache the whole read, just the start. In some sense this makes the cache seem larger. I'm not sure if OS buffer caches do this, but I kind of doubt it because they are made for a separate purpose.
3) You're ignoring writes.
Thanks for the recommendation though, and it's definitely relevant.
I remember checking it out and deciding it didn't do what I wanted. Looking at the page, I think it was the last con: "So unfortunately it will not help with the massive .gcf files in the steamapps folder itself (mostly Valve games such as Counter-Strike and the Half-Life series)."
So I've pretty much just done it manually. (If I were smart I'd use steammover for the things it works for and do other things manually, but I'm not. :-))
the only gain with these drives is on startup and then not by much
That's not quite fair. Assuming it's a write-through cache you could still see a significant write boost compared to just an SSD. And there's other data which would be beneficial to have fast access to but isn't in the OS buffer cache, for instance because you've recently turned the computer back on. For instance, I see substantially better load times in many games than I did with a HDD, even though I should have enough of a buffer cache. And while this isn't a fair comparison because I have a full SSD instead of hybrid, the benchmarks I've seen of other SSD caching solutions have looked reasonably good; from what I can tell, a lot of those improvements would translate over.
Then you don't want spinning platters in your laptop draining your battery, you want a full on SSD that just barely sips power with no speed loss.
What if you have need for a hefty amount of storage without paying through the nose? You can get a 1 TB hybrid laptop drive for much less than the cost of a full SSD that's a quarter of the size. Or a 500 GB hybrid for just a little bit more than a 128 GB SSD.
Obviously not everyone needs that space, but I certainly would if my main computer were a laptop.
The big difference with Linux is its efficiency.
For me, the differences are things like (1) better window managers, (2) better native shells (though I really like Powershell), (3) openness, and (4) a couple Linux-only apps. That's why I use Linux some of the time. Efficiency comes in... well, pretty far down the list.
At under $250 for a 256 Gig SSD, why would anyone buy a combination drive anymore?
Depending on what you do on your computer, space. For instance, I have well over 256 GB of data that would benefit substantially from SSD speeds. (For instance, games often see significantly decreased level loading times; particularly important with things like HL2 where the loads break the flow. My Steam directory alone is 132 GB.)
I don't churn through all of it regularly, but rather it'll be more like I use 20 GB for a few weeks, then switch to another 20 GB for another few weeks. This is the kind of usage that I suspect might actually benefit quite a bit from automatic caching.
I get good performance by manually copying around whatever game it is that I want to play at the moment, but deciding data should live on the HDD and what should be on the SSD is a bit of annoying work and I'm almost certainly not making the best decisions.
No; You can achieve that with a separate SSD and a mechanical drive; That's what most people are doing now anyway.
I have a separate SSD and HDD, but I also don't think that you're being entirely fair to the hybrid drives. You can set up software (bcache) or hybrid (Intel Smart Response) caching, but near as I can tell that will greatly hamper dual booting. You can keep the file systems separate (as I'm doing), but now you have to worry about manual adjustment of what data is on what drive where an automatic solution may well do better and would certainly be less work.
I'm not sure how the hybrid drive performance compares, but the Smart Response benchmarks I've seen were reasonably decent. If the hybrid drives are somewhat similar and if dual booting or something like it is important to you, it very well could be that a hybrid drive with hardware support offers the best tradeoffs.
Unclear whether this is a problem or not...
IMO it's a problem either way. The Intel "Smart Response" stuff that they introduced as a chipset feature a year or two ago (you put a HDD and SSD in your computer and it will cache stuff on the SSD) works similar. A neat idea, but a non-starter for what I wanted. Why?
Even if it works fine in Windows and works fine in Linux, it may still not really work if you want to dual boot. If you want to be able to use the SSD cache in both operating systems, they have to be able to not step on each others toes. If you want to be able to read data from the other OS, it has to be able to understand the format the other is in. (Potentially this could be "doesn't have to do anything in particular" if you make it a write-through cache, but write-back caches might have more stuff. And you still need to understand the format to write if you have a write-through cache.)
Obviously not everyone needs dual booting, but not everyone needs Linux support either. It's a bit selfish to say that it's a problem if there is only support in Windows, but it's not a problem if there is support in both OSs but the support isn't compatible. :-)
The difference is that /etc is implemented using two of the most mature and well understood pieces of the system: a file system directory hierarchy and text files.
You're simplifying.
You can't just say "text files", because I can't write "Hey Apache, I want you to put password protection on the stuff in /var/html/secret" in a file and have it work. Instead, Linux config files take many different formats, from INI-style to XML to shell scripts to custom formats like the X11 config.
I can very easily turn around the argument as follows:
"The difference is that /etc is implemented using a bunch of inconsistent formats. The Windows registry, in contrast, is implemented using a consistent, reasonably simple, typed key-value hierarchical database."
And speaking of "rich access control". /etc has extremely robust access control via the filesystem. Access control that is well tested, well documented and well understood.
The equivalent of registry-style access control would be more like separate ACLs for each line of a file. To do that, oh, you have to write a special program like crontab which runs with setuid (I guess that's what it does?) to edit the file but takes instructions from something else.
Useful? No clue, I don't do enterprise stuff. But from a pure objective level, the Windows registry offers a significantly more expressive set of security settings.
another thing windows devs don't get is shared libraries (DLLs in windows terminology). Why does every single app have to install their own copy of the MS C++ libraries? or .net? or nvidia physx? and numerous other common library packages? these things are supposed to be shared resources provided and kept up-to-date by the operating system, not bundled with every app that uses them.
They are... sort of. Take the MSVC runtime. That's not maintained or installed necessarily by the OS for (some good, some mediocre) reasons which I'll explain in a second, but I'm 95% sure that it's shared between programs in the sense that when you see an program installer that spawns off the MSVC runtime installer, the latter will either be (1) installing a new version of the MSVC runtime or (2) discovering that it's already present and doing nothing. The runtime installs to a shared location. (Look at msvc*.dll in windows\system32.) So the runtime installer has to be bundled with individual programs for the upcoming reasons, but it's not wasting disk space by installing duplicate copies (subject to the caveat below) or wasting memory by loading the same thing from different hard drive locations at different time.
So why does it do this? Well, a couple reasons, I think. (I'm speculating here, but I consider them educated guesses.) First is the mediocre reason: there's no package manager. This leads to the "well, you have to ship the runtime installer with each program."
Second is the pretty-good reason: compatibility and correctness. You can definitely have multiple major versions (e.g. the runtime associated with VS2008 and 2010) installed simultaneously, and I think you might be able to have multiple patch versions of the same library installed simultaneously. I think the former is true in Linux too (libfoo.so.1.0.0 vs libfoo.so.2.0.0, though I thought those only show up for -devel packages... hmmm, not sure), but the latter isn't so much. It may well be that Program A installs version 1.0.0 and Program B installs version 1.0.1239, where on Linux the latter would likely be packaged to upgrade the former. (This is the caveat to my "no wasted space" claim above.)
Why is that good? Well, why did the library change? Bug fix? Well, MS usually will bend over backwards to maintain compatibility, which has often meant bug-for-bug compatibility with old programs, at least as a shim. If you take the Linux approach, then programs which rely on the old behavior of the buggy code will break. This is sometimes good (e.g. bad security-related fixes), but is often not. Or it doesn't have to be a bug fix, it could just be some behavior change within the specification. By keeping multiple versions around, the Windows approach keeps the individual programs happier.
How you weight these various advantages and disadvantages is up to you. I'm not really trying to argue that the Windows approach is better, just explain why it is as it is and give a fair description of what goes on.
Crap, shoulda previewed. Sorry for the formatting. Fixed version:
Then you would end up with a massive PATH variable...
First: that's only one solution. For example, I have (issues file system query) probably three or four thousand different packages available to me right now, all installed into their own directory. (This counts multiple versions separately. As a disclamer, some of those packages are very very old and won't even run on this system as the library dependencies aren't present or they are only built for another architecture, and most of the others are obsolete and there's little reason to use them. Point being: I have access to tons of packages.) My $PATH has 21 entries, including some redundancies.
The first step to reconciling these facts is basically what you suggest later in your post: that there are multiple directories with symlinks. For instance, ~/bin is in my $PATH, and it has a few dozen symlinks to some of those packages.) But doing this or what you said ("one possibility might involve putting symlinks in /usr/bin to program files into another directory where different versions of the program can be stored") still requires a package manager which can install to a different location, which is not really supported by the Apt toolchain.
Second: just because you have a package available doesn't mean you need it in your $PATH. I have a ton of different GCC versions available, and I use three or four with some regularity. (I use even more of them infrequently.) But I don't necessarily need, say, GCC 4.5 in my $PATH. If I want 4.5 explicitly, I can always run /path/to/gcc-4.5/bin/gcc.
Third: you have to remember who Ubuntu is aimed at. It's aimed at casual users. Casual users don't even care about $PATH in the first place, because they don't start things from the command line. They just hit the windows key or whatever they do to bring up the launcher, choose what program they want to run, and click it.
They need to be respected, even if it has significant problems in some environments and fatal problems in others (e.g. mine)?
Unix had a ton of really great ideas. But many of them have run their course. You can't progress if you say you can't change stuff.
Then you would end up with a massive PATH variable...
First: that's only one solution. For example, I have (issues file system query) probably three or four thousand different packages available to me right now, all installed into their own directory. (This counts multiple versions separately. As a disclamer, some of those packages are very very old and won't even run on this system as the library dependencies aren't present or they are only built for another architecture, and most of the others are obsolete and there's little reason to use them. Point being: I have access to tons of packages.) My $PATH has 21 entries, including some redundancies.
The first step to reconciling these facts is basically what you suggest later in your post: that there are multiple directories with symlinks. For instance, ~/bin is in my $PATH, and it has a few dozen symlinks to some of those packages.) But doing this or what you said ("one possibility might involve putting symlinks in /usr/bin to program files into another directory where different versions of the program can be stored") still requires a package manager which can install to a different location, which is not really supported by the Apt toolchain.
Second: just because you have a package available doesn't mean you need it in your $PATH. I have a ton of different GCC versions available, and I use three or four with some regularity. (I use even more of them infrequently.) But I don't necessarily need, say, GCC 4.5 in my $PATH. If I want 4.5 explicitly, I can always run /path/to/gcc-4.5/bin/gcc.
Third: you have to remember who Ubuntu is aimed at. It's aimed at casual users. Casual users don't even care about $PATH in the first place, because they don't start things from the command line. They just hit the windows key or whatever they do to bring up the launcher, choose what program they want to run, and click it. ...and also does not follow the time honored Unix tradition which needs to be respected.
They need to be respected, even if it has significant problems in some environments and fatal problems in others (e.g. mine)?
We need it because while current packaging systems are great for central control, they are bad for actually letting users contribute.
One more:
e) Most current packaging systems don't let you pick an installation directory. (Many programs have directories set in stone when you compile them.)
This is one that has affected me, because in the environment I work in, we have standard stuff installed locally but a lot of more esoteric software as well as more current versions of software installed to network drives. (For instance, we run RHEL6 which comes packaged with Python 2.6, but I almost always use Python 2.7 off of the network. Or we have Clementine available for use only over the network.) But the way existing package managers work means that we can't really use them, which means that if I want to make something new available over the network, I have to go and chase down its dependencies myself and then compile everything.
3) Centralized control over what software is installed suddenly becomes difficult
I would argue that point for the most part. From some vantage point, it's already difficult to have centralized control over what's installed. After all, I can still do what I described above to install software, without the support of the package manager. It's just a pain. Or even if you switch to a better package manager that allows users to have control over what gets installed, you can still block that as an administrator by setting noexec on the drives.
I don't want to get into whether you could use DPKG packages for what they want to do; that's beyond my scope of knowledge. However, what I can tell you is that for some tasks, apt-get just flat out doesn't work.
In particular, if you want to install programs to something other than /usr (for instance, you want to install to a network drive, or without root), then the mainstream package managers just flat out don't work.
$600 is the full retail price for Photoshop CS6, not the upgrade price. The upgrade price is somewhere around $250â"300, depending on whether you have the regular or extended edition, IIRC. Maybe $350. I upgraded a few months ago, so that's from memory.
So I did a little bit of searching (admittedly right after I posted, which is when I thought of it), and I still stand by my statement mostly. From what I can tell, there is no upgrade to CS6 except from CS5. This means that if you're paying the upgrade price, you're probably upgrading every version or nearly every version anyway. So under that policy, if you're comparing the price vs someone who only upgrades every few versions, you've got to look at the full price anyway.
Now, this is a new thing with CS6 (one thing I saw made it sound like it) and older versions had a more liberal upgrade policy, but it is what Adobe was using before creative cloud was announced.
o in effect, if you don't keep paying, you lose access to your local files. Sure, you still technically have the files, but they're as useful as a condom in a nunnery.
Those condoms in a nunnery will still be useful if you later go to a brothel. [I can't believe I just typed that sentence. :-)]
But point conceded, for the most part.
It's the same reason airlines sell their plane engines to financing groups, which then lease them back to the airline
Dear God. So this has more truth to it than I assumed?
Actually more clarifications now that I've looked at the FAQ a bit:
You're forced to pay for access during months when you don't use the software - or you lose your data
Not only is this wrong for the reason I gave before (you still can use local files), but you have 90 days after cancelling your membership to still access your files. (After that, yes, you'll lose some work. Though there's still a free 2 GB you'll have access to.)
You need to be internet connected to the internet for it to work
You need a reasonably fast internet connection for it to work
You need a reasonably reliable internet connection for it to work
My once a month statement was low. The FAQ is slightly confusing, but it sounds like it will work for 6 months without an activation (just bug you once a month).
That said, the conclusion isn't wrong, only the numbers.
Sort of. That depends on your situation. For instance, as you acknowledge, your conclusion depends on the assumption that you don't upgrade each new version. Someone who does would look at the correct numbers and go "yes, this makes sense". (A different conclusion!)
And even if it doesn't reverse the cost figuring entirely, it may be the cost difference is low enough that the value is still in favor of paying a little bit more. It does no one any good to use incorrect numbers.
Buys an upgrade about every 6 years (3 major versions) at $250â"300, or to $42â"50 per year.
Where are you getting that number? Amazon's Photoshop CS6 price is over $600. Even the student/teacher version is over $300. That alone would take your 6x cost increase to 3x.
But the biggest problem I have with this arrangement is that it leaves me completely dependent upon Adobe's good graces. At any time, they can decide to crank the price to $100 per month, and I can either pay it or I lose access to all my files.
Don't think of this as Adobe implementing a Photoshop analogy to Google Docs; this isn't PS running in the browser. Instead, it's a subscription-based version of what people already have that just checks in once a month (and forces in after 6 months). You'll still be able to edit local files.