That means over time system gets loaded with orphaned files.
I may have missed something...why are files getting orphaned?
If you're confused about what files belong to what packages in FreeBSD, try the "pkg_which" command.
The comment was to "make uninstall" (as I have seen in automake generated makefiles, or mentioned by you "make deinstall" in *BSD) bogosity.
I had this experience, notably with some man pages and generated/etc/ config files, that "make (un|de)install" will not clean everything, leaving garbage in system.
I know that Debian takes care of it and I'm happy to know now that ports take care of that too.
Fortunately pretty much everyone who runs FreeBSD runs either portupgrade or portmaster. These programs essentially take the place of apt, etc, and work completely within the structure of the ports system.
Nice to know that too. I'd say that apt more flexible, but if portupgrade in the end has the same effect, then it is not relevant. I tend to keep my Debian stable system using only official stable packages so flexibility of apt becomes redundant. [ N.B. In fact, for quite long time I didn't know that was possible. Only when I tried applications from unstable/testing repos the true nature of apt showed itself. ]
P.S. It's different in Ubuntu and e.g. Debian Sid, where being on bleeding edge means that binary upgrades can break things - and sometimes do. Flexible package management becomes must have feature. But this is again different in the BSD land where separation between the OS and the ports is well outlined. While Debian is generally maintained (and regarded) as a whole, in BSD maintenance is split to accommodate different development/maintenance cycles of core and of user apps.
Last time I was checking, Windows' POSIX doesn't support fork(). Nor does it have to - for declared level of compatibility. (Whatever it is - lazy to check it.)
They also e.g. do not support signals. POSIX doesn't mandate support for all sets of features. All it requires that compatible programs can check - during compile time - which feature sets are supported, which are not.
Windows' POSIX is very similar to some heavily strip-down, *nix based embedded OSs. Few of them support fork() or threads, some support signals/RT extensions. Yet, they are POSIX compliant.
For high-profile applications like you quote it is clear that FreeBSD (as many other source based OSs) would generally provide newer version of packages.
Yet, as Debian package statistics shows, there are lots of minor applications in active used which are not really maintained anymore by their creators - essentially only Debian Developers perform maintenance on the packages.
I'm using number of such obscure, hard-to-find packages since old times. (E.g. "cons" build system). Only once stepping outside of Debian universe for a short time, I have understood how hard it is other-wise to find the applications. Some such packages do not have home pages anymore and Googling leads directly to packages.debian.org.
My friend, active FreeBSD user, was in part attracted to it because it was one of the few problem-free systems where one can compile newer KDE and Gnome versions. Yeah, it takes time. But it also worked.
As end-user goes, there is a very little difference between Linux and *BDS when some DE runs on top of it.
One of the things I like about Debian source packages, is that they can be compiled, installed, played with, upgraded, etc and finally removed - all that without a hustle.
Impression I had that ports is just a nice front-end for "./configure && make && make install". And as usually "make uninstall" is largely missing (as only few source packages provide the functionality).
That means over time system gets loaded with orphaned files.
Actually the thing which impressed me most first time I installed the Debian was that during upgrades/install of custom packages, it can also remove conflicting packages. E.g. during library migration, Debian would properly install/remove library needed by particular package version. Apps like aptitude, which can also automatically remove unused automatically installed packages, saves heck a lot of time in long run.
Ports in a way nice simple system and I like it more than e.g. Gentoo. Yet, for stable maintainable in long run system, I'd still go with Debian Stable, as it's thorough package management was more than once saving my servers from me.
That would be really bad (and is very unlikely event).
Solaris 10 is pretty much last commercial Unix which does suck but only moderately. Because only alternatives are HP-UX (dead man crawling) and AIX (IBM Global Services' private toy).
[ OK, AIX too does suck only moderately, but it's just IBM is active in relatively few markets/regions (what/how they sell/support depends on region). You can buy it, but you will not get much support from them. ]
Many companies have strategic partnership with Sun solely for its ability to provide stable, well integrated with the hardware Unix.
P.S. Though, honestly, more and more companies which had enough intelligence in past to have good relationship with Sun, also used that intelligence other way around and evaluated/deployed Linux already long time ago - everywhere where it was feasible.
So, while certainly not claiming that using Debian or even OpenBSD is a panacea for security, I have much more faith in those projects than in any closed source project.
Also, many forget that most exploits we see fixed in Windows are real vulnerabilities with code known to at least one third party. As many so called security researchers said, exploits are often traded on black market long long before some white hat finds it and reports to M$.
With Linux and *BSD, 99% of fixed exploits are precisely the vulnerabilities found by passive means like code review.
Some M$ proponents are also over-enthusiastic about address randomization. Yes, it stops script-kiddies attacks. No, it's not effective against anything else. In particular, Linux didn't have one because grsecurity folks said that it makes no sense and gave real exploit code examples how address randomization is bypassed (IIRC, key was that address randomization changes only several lower bits of address and can be bypassed by simple masking). When Linux reaches the level when even script-kiddies would target it, then it might need the address randomization. Might - because it's application logic still should permit for the exploit to do anything sensible. Highly modularized application like Internet Explorer and Outlook make perfect target, as they are connected to the whole OS. But e.g. FireFox and Evolution give exploiters much much less playing ground.
People who buy games feel being hurt by those who pirate games. What is obvious load of crap.
The actual PC game crisis was projected long time ago and number of PC market journalists have predicted that PC gaming is going to experience huge shake up. No, not because of piracy which was there since day one. But because of many many good games were already released are all are still playable. New games and ideas have to compete with huge existing catalog. Consoles have the problem to lesser extent, as they are refreshed after some time fixing bunch of technical issues, so there are more incentives for console gamers to buy new version of the same game compared to PC counterpart. Video consoles are still evolving, PC gaming is pretty much came to its plateau.
What the journalists called gamer for was to buy new games to essentially sponsor PC game developer to continue their work. Now enter DRM. As PC gaming came out of its dark BBS ages, it grew into huge business. Managerial decision to deploy DRM as a way to fend off piracy and maximize profits is only logical - from pov of manager. But it actually back-fired: gamers skipped many new DRMed games and reinstalled some 10yo classical games of the same genre.
What StarDock now tries to do is worth all support and praise we can give: they try to return PC gaming to its roots, when distance between gamers and developers was very very thin. The glorious times when publishers were actually doing what their name stands for: publishing, only publishing and no DRM non-sense.
After reading the StarDock comments, I actually want to go and buy Demigod off Impulse. Not to play - my PC barely meets recommended system requirements nor do I like GPG games - but probably as a way to support them both in their aspiration.
Considering that number of games in past experienced all sorts of save game corruptions - due to bugs - I find it OK that a game to checks for updates always.
I would really prefer if they simply add some nag screens when game played without key. That way I can try game before purchase - and most importantly I can try an up-to-date game. (N.B. I would strongly suggest to include actual street price of the game onto the nag screens. List of stores carrying it would be also great.)
Recent example: Sacred2 demo has the same patch level as one distributed on DVD. (And this is a standard for game demos.) In demo, within first ~20 minutes I found couple of glitches. In first month, Ascaron (game dev) released IIRC 2 patches. But I can't try demo with patches applied - I can't know whether the problems I have experienced are fixed or not. So how can I justify sending $50 to Ascaron for what appears to be another glitch-fest?
I think updates are important but GPG/StarDock simply didn't expected that level of interest (quickly inflated by piracy) in the new game which put pressure on their servers. I'm sure they'll learn the mistake.
Traveling around Europe in so-called "night trains" is bliss: go to bed in Switzerland, wake up in Holland. Comfort level is not best, yet it gets you to your destination and with no apparent loss of time.
Or better to say: TPB is most popular open tracker and torrent indexing system while Mininova is only torrent indexing system. Obviously since many use TPB's open tracker, many Mininova torrents have TPB as one of the trackers.
If you think about it, when somebody does HTML/CSS for several years and still can do only HTML/CSS, he deserves a laugh.
My friends and me were always open to make a quick buck in.com era and afterwards we came out not only with "did HTML", but also extensive server/client side programming/scripting/automation experience, deep knowledge of SQL (because MySQL in the times forced you to understand very well what you are doing beforehand or [...]) and also lots of *nix experience. (Well, OK, we all have masters in CS.)
Other friends who did mostly front-ends - now desktop publishing seniors. Most of them - with their knowledge of the Adobe application stack - settled in publishing industry. Their knowledge of HTML/CSS was a bonus, but not essential.
Delta packages make little sense in Debian universe: you'll never find two servers configured same way. Meaning that for the delta packages to be useful, double amount of packages has to be maintained. Actually more than double: one has to maintain the delta packages to migrate from several older versions. And for fresh installs and security updates, not only deltas but the packages themselves would also have to be available too.
As *buntus go, that might make sense. After all most people sit on a particular distro version, upgrading using the delta packages shouldn't be a problem.
In the end it all boils down to what is cheaper: bandwidth or overhead of managing the delta packages. Considering that Debian already has 30k+(?) packages and at least 3 repos of them, the overhead of managing deltas might be really high. And the bandwidth day after day is becoming cheaper and cheaper...
Very much doubt it. The average WinXP user either does not read tech news (vast majority) or as advanced user made a conscious decision to milk their WinXP system till the end.
It's been a long time since I've seen Windows forcibly reboot a machine for updates.
I haven't seen force reboots either, but the WU pop-up reminding you to restart can be very annoying. And it comes up automatically, as by default Windows is set to download and install updated automatically.
In some enterprises I have seen force reboots though. But that is a deliberate decision of the IT to force people to update their office systems.
Not to mention that if you have a lot of pending updates on Ubuntu, my experience has been that the update procedure will invariably fail and destroy the system. For example, it will ruin the network support, which is cannot be fixed because Ubuntu NEEDS network support for everything. This never happens on Windows.
Never seen the effect on recent - 8.x - *buntus.
On my 8.04, updates generally improve things. Pretty much all what people complained about in the beginning about 8.04 is long fixed by now. 8.10 in VirtualBox also had little to no problems (can't recall single one, but do not exclude that there were some) with updates.
Probably difference between Win2K->WinXP and WinXP->Vista transitions is that in Win2K->WinXP, Microsoft early announced that they would improve backward compatibility (and SP2 for WinXP contained bunch of backward compatibility improvements).
With Vista story is completely different: Microsoft officially announced that Vista would break and that they have no plans on improving backward compatibility.
While in Win2K->WinXP times nothing held you back from migrating, story isn't that rosy for most enterprises and their load of internal Windows-only business specific tools. They ran on WinNT, Win2K with SPs/hotfixes and WinXP with SP2. But for Vista (and Win7) businesses now have to rewrite many of their internal tools.
Actually many businesses are now wising up and rewrite their internal tools from Windows-only applications to Web applications.
VirtualBox would be better for unsupported OS. I wouldn't risk plugging Windows apps/services into any internet connected LAN. Even though they run under Wine.
I would try linux again if they applications were there but they just arent. You can browse, IM etc... but I do more than that.
I have pretty good experience at running Windows as VM guest on Linux. Linux as host for VMs is quite good. But of course it depends for what purposes you use your Windows...
Value of Linux becomes apparent only after you are once forced to buy batch of Windows licenses. But as private buyer concerned - who generally get "Windows [whatever]" from OEMs - there are not much reasons to even try.
The article you cite does not contain the 1-1.5 years figure anywhere.
Like all articles on Anand, it's a performance benchmark. Obviously there is no reliability numbers in the article.
How did you get that number?
Honestly, I have picked it up from discussions with other folks who have been using SSD for quite some time and actually pressed one tech support employee to provide a number. Apparently EOMs do not have numbers themselves (or no numbers they can reveal to customers), so the support guy gave his wild guess of "1-1.5 years". Doubt the number all you want. We can only hope for the drives to hold that long.
I have tried to calculate something by myself just to find that I'm no good with the numbers myself.
Let's take 64GB SSD with 100% working wear leveling. Presume that we write ~32GB of data per day (realistic, as small files updates are the main load in e.g. desktop environments). (XXX) That means that every two days whole SSD is written and the infamous "100K erase ops" counter decreases. That is 366/2 = 183 decrements per year. Peanuts compared to 100K of erase cycles. Even if we are to factor in wear level algorithm with realistic efficiency of 90-97% (as per Anand research) and that , it still results in too long longevity.
But now at the "(XXX)" point we obviously made a mistake. SSD isn't going to be overwritten completely every two days. E.g. installed OS and user files are already taking place. That means that wear leveling can only work on the free space - but not whole SSD capacity. IOW, if there is only 5% of SSD space is available, then the 5% are going to be constantly erased/written - probably much more often than once per day.
In the end, picture is even more murkier than it was in the beginning.
I found some data from Mtron (one of the few SSD oems who do quote endurance in a way that non specialists can understand). In the data sheet for their 32G product - which incidentally has 5 million cycles write endurance - they quote the write endurance for the disk as "greater than 85 years assuming 100G / day erase/write cycles" - which involves overwriting the disk 3 times a day.
The info though seems to be usual fine PR. What I see that for example Samsung quotes for 2.5" HDD MTFB of "less than 700,000 hours" (~ 80 years!!!) and for 2.4" SSD MTFB of "more than 1,000,000 hours" (~ 117 years).
Have you *ever* seen HDD surviving 80 years? Nope. (Ask any SAN admin for references.)
In other words, I'm not buying the "greater than 85 years" mark from Mtron. Equally I do not buy the numbers from Samsung.
Though in the end, it sound a bit reassuring that in that respect the SSDs at least not worse than HDDs.
Because my reading of Anand's research tells me that in active, non-stop use SSD would fail in about the same time as normal laptop 1.8"/2.5" harddrives - 1-1.5 years. Limit on number of rewrite cycles is high (~100k), yet is quite easy to reach.
Slashdot Mirror
That means over time system gets loaded with orphaned files.
I may have missed something...why are files getting orphaned?
If you're confused about what files belong to what packages in FreeBSD, try the "pkg_which" command.
The comment was to "make uninstall" (as I have seen in automake generated makefiles, or mentioned by you "make deinstall" in *BSD) bogosity.
I had this experience, notably with some man pages and generated /etc/ config files, that "make (un|de)install" will not clean everything, leaving garbage in system.
I know that Debian takes care of it and I'm happy to know now that ports take care of that too.
Fortunately pretty much everyone who runs FreeBSD runs either portupgrade or portmaster. These programs essentially take the place of apt, etc, and work completely within the structure of the ports system.
Nice to know that too. I'd say that apt more flexible, but if portupgrade in the end has the same effect, then it is not relevant. I tend to keep my Debian stable system using only official stable packages so flexibility of apt becomes redundant. [ N.B. In fact, for quite long time I didn't know that was possible. Only when I tried applications from unstable/testing repos the true nature of apt showed itself. ]
P.S. It's different in Ubuntu and e.g. Debian Sid, where being on bleeding edge means that binary upgrades can break things - and sometimes do. Flexible package management becomes must have feature. But this is again different in the BSD land where separation between the OS and the ports is well outlined. While Debian is generally maintained (and regarded) as a whole, in BSD maintenance is split to accommodate different development/maintenance cycles of core and of user apps.
Last time I was checking, Windows' POSIX doesn't support fork(). Nor does it have to - for declared level of compatibility. (Whatever it is - lazy to check it.)
They also e.g. do not support signals. POSIX doesn't mandate support for all sets of features. All it requires that compatible programs can check - during compile time - which feature sets are supported, which are not.
Windows' POSIX is very similar to some heavily strip-down, *nix based embedded OSs. Few of them support fork() or threads, some support signals/RT extensions. Yet, they are POSIX compliant.
For high-profile applications like you quote it is clear that FreeBSD (as many other source based OSs) would generally provide newer version of packages.
Yet, as Debian package statistics shows, there are lots of minor applications in active used which are not really maintained anymore by their creators - essentially only Debian Developers perform maintenance on the packages.
I'm using number of such obscure, hard-to-find packages since old times. (E.g. "cons" build system). Only once stepping outside of Debian universe for a short time, I have understood how hard it is other-wise to find the applications. Some such packages do not have home pages anymore and Googling leads directly to packages.debian.org.
My friend, active FreeBSD user, was in part attracted to it because it was one of the few problem-free systems where one can compile newer KDE and Gnome versions. Yeah, it takes time. But it also worked.
As end-user goes, there is a very little difference between Linux and *BDS when some DE runs on top of it.
What about removal of packages?
One of the things I like about Debian source packages, is that they can be compiled, installed, played with, upgraded, etc and finally removed - all that without a hustle.
Impression I had that ports is just a nice front-end for "./configure && make && make install". And as usually "make uninstall" is largely missing (as only few source packages provide the functionality).
That means over time system gets loaded with orphaned files.
Actually the thing which impressed me most first time I installed the Debian was that during upgrades/install of custom packages, it can also remove conflicting packages. E.g. during library migration, Debian would properly install/remove library needed by particular package version. Apps like aptitude, which can also automatically remove unused automatically installed packages, saves heck a lot of time in long run.
Ports in a way nice simple system and I like it more than e.g. Gentoo. Yet, for stable maintainable in long run system, I'd still go with Debian Stable, as it's thorough package management was more than once saving my servers from me.
That would be really bad (and is very unlikely event).
Solaris 10 is pretty much last commercial Unix which does suck but only moderately. Because only alternatives are HP-UX (dead man crawling) and AIX (IBM Global Services' private toy).
[ OK, AIX too does suck only moderately, but it's just IBM is active in relatively few markets/regions (what/how they sell/support depends on region). You can buy it, but you will not get much support from them. ]
Many companies have strategic partnership with Sun solely for its ability to provide stable, well integrated with the hardware Unix.
P.S. Though, honestly, more and more companies which had enough intelligence in past to have good relationship with Sun, also used that intelligence other way around and evaluated/deployed Linux already long time ago - everywhere where it was feasible.
So, while certainly not claiming that using Debian or even OpenBSD is a panacea for security, I have much more faith in those projects than in any closed source project.
Also, many forget that most exploits we see fixed in Windows are real vulnerabilities with code known to at least one third party. As many so called security researchers said, exploits are often traded on black market long long before some white hat finds it and reports to M$.
With Linux and *BSD, 99% of fixed exploits are precisely the vulnerabilities found by passive means like code review.
Some M$ proponents are also over-enthusiastic about address randomization. Yes, it stops script-kiddies attacks. No, it's not effective against anything else. In particular, Linux didn't have one because grsecurity folks said that it makes no sense and gave real exploit code examples how address randomization is bypassed (IIRC, key was that address randomization changes only several lower bits of address and can be bypassed by simple masking). When Linux reaches the level when even script-kiddies would target it, then it might need the address randomization. Might - because it's application logic still should permit for the exploit to do anything sensible. Highly modularized application like Internet Explorer and Outlook make perfect target, as they are connected to the whole OS. But e.g. FireFox and Evolution give exploiters much much less playing ground.
People who buy games feel being hurt by those who pirate games. What is obvious load of crap.
The actual PC game crisis was projected long time ago and number of PC market journalists have predicted that PC gaming is going to experience huge shake up. No, not because of piracy which was there since day one. But because of many many good games were already released are all are still playable. New games and ideas have to compete with huge existing catalog. Consoles have the problem to lesser extent, as they are refreshed after some time fixing bunch of technical issues, so there are more incentives for console gamers to buy new version of the same game compared to PC counterpart. Video consoles are still evolving, PC gaming is pretty much came to its plateau.
What the journalists called gamer for was to buy new games to essentially sponsor PC game developer to continue their work. Now enter DRM. As PC gaming came out of its dark BBS ages, it grew into huge business. Managerial decision to deploy DRM as a way to fend off piracy and maximize profits is only logical - from pov of manager. But it actually back-fired: gamers skipped many new DRMed games and reinstalled some 10yo classical games of the same genre.
What StarDock now tries to do is worth all support and praise we can give: they try to return PC gaming to its roots, when distance between gamers and developers was very very thin. The glorious times when publishers were actually doing what their name stands for: publishing, only publishing and no DRM non-sense.
After reading the StarDock comments, I actually want to go and buy Demigod off Impulse. Not to play - my PC barely meets recommended system requirements nor do I like GPG games - but probably as a way to support them both in their aspiration.
Considering that number of games in past experienced all sorts of save game corruptions - due to bugs - I find it OK that a game to checks for updates always.
I would really prefer if they simply add some nag screens when game played without key. That way I can try game before purchase - and most importantly I can try an up-to-date game. (N.B. I would strongly suggest to include actual street price of the game onto the nag screens. List of stores carrying it would be also great.)
Recent example: Sacred2 demo has the same patch level as one distributed on DVD. (And this is a standard for game demos.) In demo, within first ~20 minutes I found couple of glitches. In first month, Ascaron (game dev) released IIRC 2 patches. But I can't try demo with patches applied - I can't know whether the problems I have experienced are fixed or not. So how can I justify sending $50 to Ascaron for what appears to be another glitch-fest?
I think updates are important but GPG/StarDock simply didn't expected that level of interest (quickly inflated by piracy) in the new game which put pressure on their servers. I'm sure they'll learn the mistake.
Traveling around Europe in so-called "night trains" is bliss: go to bed in Switzerland, wake up in Holland. Comfort level is not best, yet it gets you to your destination and with no apparent loss of time.
Hint: in recent years number of private torrent forums rose sharply.
Or better to say: TPB is most popular open tracker and torrent indexing system while Mininova is only torrent indexing system. Obviously since many use TPB's open tracker, many Mininova torrents have TPB as one of the trackers.
If you think about it, when somebody does HTML/CSS for several years and still can do only HTML/CSS, he deserves a laugh.
My friends and me were always open to make a quick buck in .com era and afterwards we came out not only with "did HTML", but also extensive server/client side programming/scripting/automation experience, deep knowledge of SQL (because MySQL in the times forced you to understand very well what you are doing beforehand or [...]) and also lots of *nix experience. (Well, OK, we all have masters in CS.)
Other friends who did mostly front-ends - now desktop publishing seniors. Most of them - with their knowledge of the Adobe application stack - settled in publishing industry. Their knowledge of HTML/CSS was a bonus, but not essential.
Web Designer. At least that title was used a lot in off-shores/out-sourcing companies I had to deal with.
Web Developer was also used, but to lesser extent and only to distinguish those who can also do JavaScript, PHP, Perl, etc.
Easiest way to find the word du jour is to check job listings.
Delta packages make little sense in Debian universe: you'll never find two servers configured same way. Meaning that for the delta packages to be useful, double amount of packages has to be maintained. Actually more than double: one has to maintain the delta packages to migrate from several older versions. And for fresh installs and security updates, not only deltas but the packages themselves would also have to be available too.
As *buntus go, that might make sense. After all most people sit on a particular distro version, upgrading using the delta packages shouldn't be a problem.
In the end it all boils down to what is cheaper: bandwidth or overhead of managing the delta packages. Considering that Debian already has 30k+(?) packages and at least 3 repos of them, the overhead of managing deltas might be really high. And the bandwidth day after day is becoming cheaper and cheaper...
Very much doubt it. The average WinXP user either does not read tech news (vast majority) or as advanced user made a conscious decision to milk their WinXP system till the end.
It's been a long time since I've seen Windows forcibly reboot a machine for updates.
I haven't seen force reboots either, but the WU pop-up reminding you to restart can be very annoying. And it comes up automatically, as by default Windows is set to download and install updated automatically.
In some enterprises I have seen force reboots though. But that is a deliberate decision of the IT to force people to update their office systems.
Not to mention that if you have a lot of pending updates on Ubuntu, my experience has been that the update procedure will invariably fail and destroy the system. For example, it will ruin the network support, which is cannot be fixed because Ubuntu NEEDS network support for everything. This never happens on Windows.
Never seen the effect on recent - 8.x - *buntus.
On my 8.04, updates generally improve things. Pretty much all what people complained about in the beginning about 8.04 is long fixed by now. 8.10 in VirtualBox also had little to no problems (can't recall single one, but do not exclude that there were some) with updates.
Probably difference between Win2K->WinXP and WinXP->Vista transitions is that in Win2K->WinXP, Microsoft early announced that they would improve backward compatibility (and SP2 for WinXP contained bunch of backward compatibility improvements).
With Vista story is completely different: Microsoft officially announced that Vista would break and that they have no plans on improving backward compatibility.
While in Win2K->WinXP times nothing held you back from migrating, story isn't that rosy for most enterprises and their load of internal Windows-only business specific tools. They ran on WinNT, Win2K with SPs/hotfixes and WinXP with SP2. But for Vista (and Win7) businesses now have to rewrite many of their internal tools.
Actually many businesses are now wising up and rewrite their internal tools from Windows-only applications to Web applications.
VirtualBox would be better for unsupported OS. I wouldn't risk plugging Windows apps/services into any internet connected LAN. Even though they run under Wine.
I would try linux again if they applications were there but they just arent. You can browse, IM etc... but I do more than that.
I have pretty good experience at running Windows as VM guest on Linux. Linux as host for VMs is quite good. But of course it depends for what purposes you use your Windows...
Value of Linux becomes apparent only after you are once forced to buy batch of Windows licenses. But as private buyer concerned - who generally get "Windows [whatever]" from OEMs - there are not much reasons to even try.
The article you cite does not contain the 1-1.5 years figure anywhere.
Like all articles on Anand, it's a performance benchmark. Obviously there is no reliability numbers in the article.
How did you get that number?
Honestly, I have picked it up from discussions with other folks who have been using SSD for quite some time and actually pressed one tech support employee to provide a number. Apparently EOMs do not have numbers themselves (or no numbers they can reveal to customers), so the support guy gave his wild guess of "1-1.5 years". Doubt the number all you want. We can only hope for the drives to hold that long.
I have tried to calculate something by myself just to find that I'm no good with the numbers myself.
Let's take 64GB SSD with 100% working wear leveling. Presume that we write ~32GB of data per day (realistic, as small files updates are the main load in e.g. desktop environments). (XXX) That means that every two days whole SSD is written and the infamous "100K erase ops" counter decreases. That is 366/2 = 183 decrements per year. Peanuts compared to 100K of erase cycles. Even if we are to factor in wear level algorithm with realistic efficiency of 90-97% (as per Anand research) and that , it still results in too long longevity.
But now at the "(XXX)" point we obviously made a mistake. SSD isn't going to be overwritten completely every two days. E.g. installed OS and user files are already taking place. That means that wear leveling can only work on the free space - but not whole SSD capacity. IOW, if there is only 5% of SSD space is available, then the 5% are going to be constantly erased/written - probably much more often than once per day.
In the end, picture is even more murkier than it was in the beginning.
Yep, I've read that.
Apparently, storage manufacturers include the MTBF because it is TOTALLY unrelated to real life. And no doubt it looks good in ads.
Thanks for the link. Quote:
I found some data from Mtron (one of the few SSD oems who do quote endurance in a way that non specialists can understand). In the data sheet for their 32G product - which incidentally has 5 million cycles write endurance - they quote the write endurance for the disk as "greater than 85 years assuming 100G / day erase/write cycles" - which involves overwriting the disk 3 times a day.
The info though seems to be usual fine PR. What I see that for example Samsung quotes for 2.5" HDD MTFB of "less than 700,000 hours" (~ 80 years!!!) and for 2.4" SSD MTFB of "more than 1,000,000 hours" (~ 117 years).
Have you *ever* seen HDD surviving 80 years? Nope. (Ask any SAN admin for references.)
In other words, I'm not buying the "greater than 85 years" mark from Mtron. Equally I do not buy the numbers from Samsung.
Though in the end, it sound a bit reassuring that in that respect the SSDs at least not worse than HDDs.
Hm... Actually Googling for "politicians background check before appointment" gave for example the link.
Any chances that you still have the link(s)?
Because my reading of Anand's research tells me that in active, non-stop use SSD would fail in about the same time as normal laptop 1.8"/2.5" harddrives - 1-1.5 years. Limit on number of rewrite cycles is high (~100k), yet is quite easy to reach.