If you're using engine check lights as an analogy to SMART data so you know when to swap out a drive, I still disagree. Once SMART data goes bad, you can usually still get data off the drive but I wouldn't trust it to not have some corruption. I'd just yank the drive, rebuild the RAID if the machine needs high availability, or copy over from backup if it doesn't.
If recovering from backup and the backup isn't quite up to date I'd probably try some kind of data recovery, but I wouldn't want to rely on it.
Compiling is almost ALWAYS IO bound for a project of any size. Why do you think make -j 4 or make -j 8 makes a noticeable difference on even single core machines? Because the compiler spends most of its time waiting on disk IO, reading and writing all those intermediate files.
From my experience when I toyed around with Gentoo a few years ago, make -j worked best when the number provided was {core count + 1}. Any more than that and it slowed down due to context switching overhead and/or disk head thrashing.
VisualStudio also supports parallel compilers for this exact same reason.
It has severe limitations. It doesn't work when you need to import TLB files, it does not work with incremental rebuilds, and it doesn't play particularly nicely with precompiled headers. The former is required for our project to build at all, and the latter 2 improve productivity more than using multiple threads (YMMV).
Hard drives typically have shorter warranties than SSDs. OCZ has a bad reputation for having reliability issues compared to other SSDs yet their warranties are 3-5 years. The typical Seagate and WD warranties are now 2 years.
I've been running multiple partitions/drives on Windows for years and haven't encountered a sizeable app that I'd want to put on a different drive that wouldn't let me.
Fairly large codebase here, ~4 minute compile times, C++ with Visual Studio. Compile times were unaffected by the SSD upgrade. Searching code, however, massive speed improvement and paid itself off with productivity improvements after about a month.
I upgraded to an SSD recently and compile times didn't really change at all, which was surprising. Boot times, application load times, system responsiveness etc however are massively improved. At least on my setup (Xeon E31270, Windows 7, Visual Studio), compile times aren't particularly IO limited.
That's just asinine. You should never rely on recovery of data from a broken drive to avoid data loss. Even if you do recover data from a broken HDD you shouldn't trust it hasn't had some form of corruption. Always have a backup. If you have backups, who cares if the drive is recoverable?
Also, don't buy Sandforce SSDs. There are plenty of alternatives that are faster and more reliable.
Open source communities can buy patents and use them to gain market share or revenue via licensing if they want, there's nothing inherent about releasing source that prohibits owning patents. They're expensive and difficult to acquire though which is why you don't often see it, so claiming a net benefit there is a bit of a stretch too.
Trade secrets on the other hand? The secrets are in the source, which once opened are no longer secret. I can't find any far-fetched argument that supports trade secret law in an OSS manner.
No, the announcement was for an OPT OUT system. They backtracked claiming they meant for it to be opt in, yet how something like that gets written up in sufficient detail describing how the opt out system would work when they intended opt in just boggles the mind (read: they're a pack of liars).
Here is hoping the next CEO hires the Jolla and Neo900(N900 based GTA04 mod OpenMoko upgrade system board) team and they get back to making amazing hardware with a great OS.
Then I wake up...
This is about replacing the Microsoft CEO not Nokia CEO. As much as we talk about smartphones here Elops most criminal cut was Meltemi a featurephone OS aimed at low hardware.
If Elop does move back to Microsoft, Nokia would then need a replacement CEO, no?
Re:What's good for others apparently is no good fo
on
Break Microsoft Up
·
· Score: 1
So, what was better? At the time, Windows Mobile was pretty much the only option even though it sucked.
Those features I mentioned will affect existing apps, not just apps to be newly released. Developers would like to test to make sure the new features don't interact poorly with existing apps.
Are the existing apps using the new APIs? Do they operate poorly in the Preview?
I don't think the apps call any APIs to trigger the new functionality, I believe the OS just does its thing assuming the apps will behave correctly. Considering part of the reason the original Metro split screen stuff was so limited was because Microsoft "guaranteed" that apps will only run 1/3, 2/3 or 3/3 of the screen, it's quite likely some apps won't behave correctly when resized to an arbitrary size. Running in the preview *should* be sufficient to test for this, but there's no guarantee the preview behaves exactly like RTM.
It doesn't really matter how it's done in the Android world, the point is that developers currently pay for MSDN subscriptions precisely to get access to Microsoft software for development purposes and now those perks are largely useless. It's a regression on a paid subscription, we have every right to be unhappy about it.
So it's less a matter of process - since in the Android world we do this all the time - and more a matter of regression of value in the paid subscription...well maybe it's time to cancel that subscription then.
With Microsoft cancelling TechNet and devaluing MSDN, I wouldn't be surprised if that starts happening soon.
Those features I mentioned will affect existing apps, not just apps to be newly released. Developers would like to test to make sure the new features don't interact poorly with existing apps.
It doesn't really matter how it's done in the Android world, the point is that developers currently pay for MSDN subscriptions precisely to get access to Microsoft software for development purposes and now those perks are largely useless. It's a regression on a paid subscription, we have every right to be unhappy about it.
Slashdot Mirror
That's an in-band means.
No. The music library is outside the sandbox.
That surprised me because they are planning Office on Apple
Planning? Office for Mac has been around for around 24 years.
Or they're sandboxed to an "open" Battle.Net. Like Diablo 2.
For me, it didn't survive a month. And I played D2 for ~5 years.
If you're using engine check lights as an analogy to SMART data so you know when to swap out a drive, I still disagree. Once SMART data goes bad, you can usually still get data off the drive but I wouldn't trust it to not have some corruption. I'd just yank the drive, rebuild the RAID if the machine needs high availability, or copy over from backup if it doesn't.
If recovering from backup and the backup isn't quite up to date I'd probably try some kind of data recovery, but I wouldn't want to rely on it.
Compiling is almost ALWAYS IO bound for a project of any size. Why do you think make -j 4 or make -j 8 makes a noticeable difference on even single core machines? Because the compiler spends most of its time waiting on disk IO, reading and writing all those intermediate files.
From my experience when I toyed around with Gentoo a few years ago, make -j worked best when the number provided was {core count + 1}. Any more than that and it slowed down due to context switching overhead and/or disk head thrashing.
VisualStudio also supports parallel compilers for this exact same reason.
It has severe limitations. It doesn't work when you need to import TLB files, it does not work with incremental rebuilds, and it doesn't play particularly nicely with precompiled headers. The former is required for our project to build at all, and the latter 2 improve productivity more than using multiple threads (YMMV).
They only need to run 1.5 million drives for 1 hour to reach that MTBF. If 5% of them die after 2 hours they still hit the MTBF.
There's a reason people back up data rather than relying on data recovery on a broken drive.
Hard drives typically have shorter warranties than SSDs. OCZ has a bad reputation for having reliability issues compared to other SSDs yet their warranties are 3-5 years. The typical Seagate and WD warranties are now 2 years.
Warranties are typically longer on SSDs than HDDs these days. I can't comment on the specific models they used in the article however.
I've been running multiple partitions/drives on Windows for years and haven't encountered a sizeable app that I'd want to put on a different drive that wouldn't let me.
Fairly large codebase here, ~4 minute compile times, C++ with Visual Studio. Compile times were unaffected by the SSD upgrade. Searching code, however, massive speed improvement and paid itself off with productivity improvements after about a month.
I upgraded to an SSD recently and compile times didn't really change at all, which was surprising. Boot times, application load times, system responsiveness etc however are massively improved. At least on my setup (Xeon E31270, Windows 7, Visual Studio), compile times aren't particularly IO limited.
That's just asinine. You should never rely on recovery of data from a broken drive to avoid data loss. Even if you do recover data from a broken HDD you shouldn't trust it hasn't had some form of corruption. Always have a backup. If you have backups, who cares if the drive is recoverable?
Also, don't buy Sandforce SSDs. There are plenty of alternatives that are faster and more reliable.
Open source communities can buy patents and use them to gain market share or revenue via licensing if they want, there's nothing inherent about releasing source that prohibits owning patents. They're expensive and difficult to acquire though which is why you don't often see it, so claiming a net benefit there is a bit of a stretch too.
Trade secrets on the other hand? The secrets are in the source, which once opened are no longer secret. I can't find any far-fetched argument that supports trade secret law in an OSS manner.
Not all Australian residents are Australian citizens over the age of 18.
Everyone except Canonical are switching to Wayland.
No, the announcement was for an OPT OUT system. They backtracked claiming they meant for it to be opt in, yet how something like that gets written up in sufficient detail describing how the opt out system would work when they intended opt in just boggles the mind (read: they're a pack of liars).
Doesn't necessarily mean they know the decryption keys does it?
Here is hoping the next CEO hires the Jolla and Neo900(N900 based GTA04 mod OpenMoko upgrade system board) team and they get back to making amazing hardware with a great OS. Then I wake up...
This is about replacing the Microsoft CEO not Nokia CEO. As much as we talk about smartphones here Elops most criminal cut was Meltemi a featurephone OS aimed at low hardware.
If Elop does move back to Microsoft, Nokia would then need a replacement CEO, no?
So, what was better? At the time, Windows Mobile was pretty much the only option even though it sucked.
Those features I mentioned will affect existing apps, not just apps to be newly released. Developers would like to test to make sure the new features don't interact poorly with existing apps.
Are the existing apps using the new APIs? Do they operate poorly in the Preview?
I don't think the apps call any APIs to trigger the new functionality, I believe the OS just does its thing assuming the apps will behave correctly. Considering part of the reason the original Metro split screen stuff was so limited was because Microsoft "guaranteed" that apps will only run 1/3, 2/3 or 3/3 of the screen, it's quite likely some apps won't behave correctly when resized to an arbitrary size. Running in the preview *should* be sufficient to test for this, but there's no guarantee the preview behaves exactly like RTM.
It doesn't really matter how it's done in the Android world, the point is that developers currently pay for MSDN subscriptions precisely to get access to Microsoft software for development purposes and now those perks are largely useless. It's a regression on a paid subscription, we have every right to be unhappy about it.
So it's less a matter of process - since in the Android world we do this all the time - and more a matter of regression of value in the paid subscription...well maybe it's time to cancel that subscription then.
With Microsoft cancelling TechNet and devaluing MSDN, I wouldn't be surprised if that starts happening soon.
Those features I mentioned will affect existing apps, not just apps to be newly released. Developers would like to test to make sure the new features don't interact poorly with existing apps.
It doesn't really matter how it's done in the Android world, the point is that developers currently pay for MSDN subscriptions precisely to get access to Microsoft software for development purposes and now those perks are largely useless. It's a regression on a paid subscription, we have every right to be unhappy about it.
Yes, they are in the Preview, but as a developer I'd still want to test on RTM before customers get their hands on it.