One day, with a traditional HDD based setup, you'll come into the office to find the place a mess, everyone standing around and when you ask "what's happened", you'll get the reply "we were burgled, your PC is right now being sold on ebay".
So who cares whether SSDs fail immediately or with a huge flashy light show whilst beeping out La Marseillaise, it won't help you none.
You'll find other stories of HDD RAID that failed simultaneously (which is more common than you think, drives go bad in batches, or I think, die at the same time just out of stubborness) either due to power surges, or raid failure that led to data corruption.
So the only solution is to have adequate backup. With the number of continuous backup solutions out there, there's no excuse not to run it.
PS. you replaced your SSDs with a pair or HDDs in RAID 0 format. Beggers belief.
sigh, someone else who didn't RTFA. If you look on page 8 you'll see this image where Intel's 'reliability study at IDF 2011' says HDDs are pants, SSDs are great.
of course, this is part of Intel's marketing for SSDs, so you'd expect them to say this kind of thing. Of course, that means someone has said this - specifically as some sort of selling point.
the number of people who bothered to build Firefox from source is a small minority compared to those who downloaded it.
true, but so what. That 1 or 2 security researchers (who obviously have different ideals to the rest of us) can and will analyse the code means that you and I get the benefit of their expertise.
Just because I don't look at the source doesn't mean there's no value in having it available. And I think you'll find that users do care that someone else has this opportunity.
Simple. They hire Bruce Schneier and he arranges for man-in-the-middle attacks on all your traffic. Google can then also insert some ads into the encrypted stream as your users surf your site, thus keeping the service free for the rest of us:)
that's not surprising - you checkout the git repo, whereas svn you checkout the parts you need. If I copied the svn repo directly to my PC, it'd be smaller. Still, that's not the point - you should see our main repo at work, its huge as it has many years of history in it. With git, that's be a 40gb download. With svn, I ignore 90% of it. That was my point and the common usage of both.
Not that its a disadvantage per-se, the clone model has many advantages, but they become less relevant as your repo grows.
As for your work svn layout.. poor you. I'm sure people who think like that could find ways to screw up your git repo too. Just be glad they're not using an expensive, 'enterprise' tool for this. You could have the pain of a really wonky layout *and* the pain of Dimensions or PVCS:)
Re:Data, Images, Binary builds etc.
on
The Rise of Git
·
· Score: 1
I have source code from 1990 in the main app I work with, does that mean I should take that out of my source code repository?
Just because an image doesn't change often does not mean it shouldn't be controlled along with the rest of the source code. Putting it somewhere else simply means you're running a good risk of losing it, getting it confused with other versions (when it does eventually change) or, at best, being a nuisance for all your developers. You need to put everything in your main repo that is your app. If your tool doesn't support that, get a new tool.
Its hardly the first one to do this, Mozy does the same - it allows you to use your own keys to encrypt all your data that's transferred. (you can use Mozy's keys instead which provides for more convenience, but hey - your choice)
It also has a nice interface to download your files - integrated as an Explorer shell extension (if you're on Windows). It doesn't provide a 'ftp' facility though.. but I think I'll suggest that to them.. instead its more a backup tool - just like Spideroak.
note: that link is an affiliate, they'll give me more backup space if you use it, if you don't want to, google 'Mozy' instead.
Google attempted to deliberately record the location of all open wifi hotspots. What the 'accidental' part was, is that they recorded all the open wifi hotspots that shouldn't have been open - ie home users who hadn't protected their devices.
From a technical viewpoint, there's no difference between Starbuck's open wifi, and the one at my home. The point of all this is that Google's access wasn't malicious, they did accidentally collect data they didn't intend to - which is very obvious after the fact, I guess no-one thought about it enough beforehand.
You'll find a lot of corporate type environments have this much code (and other artifacts) in their SCMs, partly because they store lots of stuff, partly becuase of the large amount of history.
SVN handles this well as you can cherry pick pieces to checkout - google 'sparse directories' for details. You have to split your repo into submodules or separate projects when using git.
Re:Data, Images, Binary builds etc.
on
The Rise of Git
·
· Score: 3, Insightful
and you've just screwed the entire configuration process there.
The whole point of a SCM is that you put your sources in there so you can check it out and get the same set of sources from any point in history. The moment you say "oh that's too big, we'll put it somewhere else" is the day you lose control of that reproducability.
Your images used in the app are part of the source. While there's a place for storing data elsewhere, it still has to be controlled in a way that you can get it back out again for a particular version.
For example, they take up a linearly larger amount of space on your local storage media when checking everything out
when you clone a git repo, you get everything checked out anyway, so you're not saving any space at all. This isn't like SVN's sparse directory feature where you can checkout partial repositories, with git you (practically) have to check it all out to use all its useful features.
the difference between a 2d representation of branches (ie everythign laid out flat in a directory structure), and a 3d one (ie 1 directory that has thebranches 'overlaid' on it) is just syntactic sugar. If you're ever trying to use relative paths between branches (and trunk is effectively a branch), then you're in a world of stupid.
To promote the Progress of... useful Arts, by securing for limited Times to... Inventors
and I think that's the problem with the patent system as it stands, the patents that are being legislated over don't appear to be 'inventions' but somewhat vague concepts.
Its just a good job we can't remember the fabulous ideas we come up with when drunk/stoned or the no-one would be able to do anything without infringing one:)
the other aspect of NFC that no-one seems to notice is that it'll be off all the time until you want to use it. You can't just click your phone against the reader to transfer money, you have to unlock the phone (at least) first. They say the only way to get security is to unplug from the network - this does that.
Incidentally I've heard of using NFC for pairing, followed by Bluetooth for data transfer. No more typing in codes to your bluetooth device, connect via NFC to enter the codes automatically.
$10k coding $90k testing $299.9m shuffling paper from one project manager to a quality manager to a process manager to an oversight manager to a test manager to a project manager to a procedure manager to an environments manager to an integration manager to a contractor who does all of the above all over again.
I'm sure there's a 'profit???' in there somewhere:)
I think there's a limit to how big your readyboost cache canbe before it starts to degrade performance - if you're reading all the time, then it's fine, but when you start to write you have to write to both your SSD and the backing store or invalidate the cached data you've just modified.
Besides, a USB flash drive comes in sizes up to 128Gb, and they're a lot cheaper than SSDs. If you have a SSD, install it as a drive!
you keep telling yourself that, and the day they outsource you (regardless of your skills) because Pradesh and chums can (supposedly) do your job way cheaper (and the boss gets a bonus for reducing operational costs) is the day you realise what the problem could be.
doesn't matter how much surface area is road, you can install heat-exchanger systems in carparks and heat (and cool) buildings directly from their own carparking.
That said, a study has said that if 15% of Holland's had such a system installed, it would produce more energy that all the power utilities do, combined. It also means that roads last longer as they wouldn't freeze so easily and therefore develop cracks and potholes, nor have to be covered with rock salt to de-ice them.
I'm not so convinced by that argument, even if it has some appeal.
What I think happens (as someone who's been around the industry for a few years now) is that you become less interested in the technology, and more interested in making things. ie, I can no longer get enthused about the current cool framework, or how easy the new language can make things. I do get excited about making the products that we sell to our customers though, and doing a good job of it. I guess I'm just maturing a bit and starting to do the job rather than playing with the toys.
The ideal is probably a good mix of ages, you want the older guys doing designs and architecture, coming up with the requirements and user stories, and the younger guys slapping together the code - which is really what they like. As long as management stops promoting the young guys into positions where they decide how things should be put together, then we'll keep on with rewrites and poor code that's oh-so-cool but oh-so-useless.
Or maybe I'm just spouting nonsense and the real industry is filled with all sorts of people in all sorts of roles, no matter what age they are:)
you definitely don;t use the version number, unless you're running Microsoft software and want to wait for the 3rd release as that's always the one that works. Even then, MS has cottoned on to this and releases products with all kinds of arbitrary version numbers to confuse you into buying not-ready releases.
Or maybe its because if you charged a fee to use the service, you'd have to increase the price to account for the servicing overhead - either an attendant, or an automated ticket system with cut-off timers and all the associated electronics.
Instead its better to charge once via taxes or grants and then allow useage for free. More people will use it and the cost of providing the service will be much reduced.
ah no. Its not about the 'bean counters' as they do a very good job counting beans and distributing them about - every business needs a good accounts department. There's also a lot to be said about running a business well, ensuring things like your production costs don't swamp the business and there's enough left in the pot to handle some lean years when you have the usual troughs in sales.
No, the problem is the 'management' who only count the beans they can get their hands on to the detriment of everything else. Where a focus is on short-term management of the numbers geared specifically for their own benefit, you know - "maximising profit" to get a better bonus even though it means laying off half the workforce; where product quality is secondary to end-quarter results even if it means releasing dangerous products as long as the current target is met, making the bonus payments flow in.
Most MBAs last 2 years at a company before moving on to destroy another one. Take a look at Nokia for the perfect example. Elop.. couldn't hack it anywhere for more than 2 years, and now is screwing Nokia and expects to gain a huge merger bonus (possibly when MS buys Nokia in a couple of years).
there are many tools that produce better software quality, btu they all seem to be up-front, and require a large amount of programmer time. This is probably because they are produced by programmers for programmers.
so test-driven-development is very fashionable at the moment, even though it doesn't really work well with legacy code and can take an amazing amount of time to set up for new; similarly code reviews are great, but require lots of time for a (presumably) better coder to check what you did is ok (as a cursory look through to spot the glaringly obvious problems isn't too much use).
So why do we spend so much programmer time checking and rechecking, when we can test the system like we used to in the old days. Not only can you get dedicated testers (who have fresh eyes on the problem), but they test all the other aspects that code review and unit test would miss.
I know there are places where unit tests are very good - regression testing a library for example, and code reviews are good for the blindingly obvious errors, but too much emphasis are given to these for almost every part of software nowadays. For example, I read today (on stackoverflow) that someone decided to use TDD for his new project and wrote 50 tests per module and it took him ages to get 100% test coverage, and now he can't bring himself to write a new module because it takes so long and is so unproductive. The answers were generally of "you're writing too many tests, 80% coverage is really good", but then.. if you only unit test 80% of your system, you're going to have to 'system test' the whole thing anyway!
So, I think they have their place, but they're not magic bullets of software quality, no matter how much my boss (who's been reading these blogs on the internet again) thinks they will be.
Slashdot Mirror
always remember: RAID is not backup.
One day, with a traditional HDD based setup, you'll come into the office to find the place a mess, everyone standing around and when you ask "what's happened", you'll get the reply "we were burgled, your PC is right now being sold on ebay".
So who cares whether SSDs fail immediately or with a huge flashy light show whilst beeping out La Marseillaise, it won't help you none.
You'll find other stories of HDD RAID that failed simultaneously (which is more common than you think, drives go bad in batches, or I think, die at the same time just out of stubborness) either due to power surges, or raid failure that led to data corruption.
So the only solution is to have adequate backup. With the number of continuous backup solutions out there, there's no excuse not to run it.
PS. you replaced your SSDs with a pair or HDDs in RAID 0 format. Beggers belief.
sigh, someone else who didn't RTFA. If you look on page 8 you'll see this image where Intel's 'reliability study at IDF 2011' says HDDs are pants, SSDs are great.
of course, this is part of Intel's marketing for SSDs, so you'd expect them to say this kind of thing. Of course, that means someone has said this - specifically as some sort of selling point.
the number of people who bothered to build Firefox from source is a small minority compared to those who downloaded it.
true, but so what. That 1 or 2 security researchers (who obviously have different ideals to the rest of us) can and will analyse the code means that you and I get the benefit of their expertise.
Just because I don't look at the source doesn't mean there's no value in having it available. And I think you'll find that users do care that someone else has this opportunity.
Simple. They hire Bruce Schneier and he arranges for man-in-the-middle attacks on all your traffic. Google can then also insert some ads into the encrypted stream as your users surf your site, thus keeping the service free for the rest of us :)
that's not surprising - you checkout the git repo, whereas svn you checkout the parts you need. If I copied the svn repo directly to my PC, it'd be smaller. Still, that's not the point - you should see our main repo at work, its huge as it has many years of history in it. With git, that's be a 40gb download. With svn, I ignore 90% of it. That was my point and the common usage of both.
Not that its a disadvantage per-se, the clone model has many advantages, but they become less relevant as your repo grows.
As for your work svn layout.. poor you. I'm sure people who think like that could find ways to screw up your git repo too. Just be glad they're not using an expensive, 'enterprise' tool for this. You could have the pain of a really wonky layout *and* the pain of Dimensions or PVCS :)
I have source code from 1990 in the main app I work with, does that mean I should take that out of my source code repository?
Just because an image doesn't change often does not mean it shouldn't be controlled along with the rest of the source code. Putting it somewhere else simply means you're running a good risk of losing it, getting it confused with other versions (when it does eventually change) or, at best, being a nuisance for all your developers. You need to put everything in your main repo that is your app. If your tool doesn't support that, get a new tool.
Its hardly the first one to do this, Mozy does the same - it allows you to use your own keys to encrypt all your data that's transferred. (you can use Mozy's keys instead which provides for more convenience, but hey - your choice)
It also has a nice interface to download your files - integrated as an Explorer shell extension (if you're on Windows). It doesn't provide a 'ftp' facility though.. but I think I'll suggest that to them .. instead its more a backup tool - just like Spideroak.
note: that link is an affiliate, they'll give me more backup space if you use it, if you don't want to, google 'Mozy' instead.
Google attempted to deliberately record the location of all open wifi hotspots. What the 'accidental' part was, is that they recorded all the open wifi hotspots that shouldn't have been open - ie home users who hadn't protected their devices.
From a technical viewpoint, there's no difference between Starbuck's open wifi, and the one at my home. The point of all this is that Google's access wasn't malicious, they did accidentally collect data they didn't intend to - which is very obvious after the fact, I guess no-one thought about it enough beforehand.
I do!
You'll find a lot of corporate type environments have this much code (and other artifacts) in their SCMs, partly because they store lots of stuff, partly becuase of the large amount of history.
SVN handles this well as you can cherry pick pieces to checkout - google 'sparse directories' for details. You have to split your repo into submodules or separate projects when using git.
and you've just screwed the entire configuration process there.
The whole point of a SCM is that you put your sources in there so you can check it out and get the same set of sources from any point in history. The moment you say "oh that's too big, we'll put it somewhere else" is the day you lose control of that reproducability.
Your images used in the app are part of the source. While there's a place for storing data elsewhere, it still has to be controlled in a way that you can get it back out again for a particular version.
For example, they take up a linearly larger amount of space on your local storage media when checking everything out
when you clone a git repo, you get everything checked out anyway, so you're not saving any space at all. This isn't like SVN's sparse directory feature where you can checkout partial repositories, with git you (practically) have to check it all out to use all its useful features.
the difference between a 2d representation of branches (ie everythign laid out flat in a directory structure), and a 3d one (ie 1 directory that has thebranches 'overlaid' on it) is just syntactic sugar. If you're ever trying to use relative paths between branches (and trunk is effectively a branch), then you're in a world of stupid.
There's the relatively new ubersvn which is a 'install in one go' type system that also adds a loads of additional features including a 'social hub'
To promote the Progress of... useful Arts, by securing for limited Times to... Inventors
and I think that's the problem with the patent system as it stands, the patents that are being legislated over don't appear to be 'inventions' but somewhat vague concepts.
Its just a good job we can't remember the fabulous ideas we come up with when drunk/stoned or the no-one would be able to do anything without infringing one :)
the other aspect of NFC that no-one seems to notice is that it'll be off all the time until you want to use it. You can't just click your phone against the reader to transfer money, you have to unlock the phone (at least) first. They say the only way to get security is to unplug from the network - this does that.
Incidentally I've heard of using NFC for pairing, followed by Bluetooth for data transfer. No more typing in codes to your bluetooth device, connect via NFC to enter the codes automatically.
sigh. I won't even like to the article, but to a fellow /.er who has:
http://news.slashdot.org/comments.pl?sid=2341450&cid=36836046
Probably:
$10k coding
$90k testing
$299.9m shuffling paper from one project manager to a quality manager to a process manager to an oversight manager to a test manager to a project manager to a procedure manager to an environments manager to an integration manager to a contractor who does all of the above all over again.
I'm sure there's a 'profit???' in there somewhere :)
I think there's a limit to how big your readyboost cache canbe before it starts to degrade performance - if you're reading all the time, then it's fine, but when you start to write you have to write to both your SSD and the backing store or invalidate the cached data you've just modified.
Besides, a USB flash drive comes in sizes up to 128Gb, and they're a lot cheaper than SSDs. If you have a SSD, install it as a drive!
you keep telling yourself that, and the day they outsource you (regardless of your skills) because Pradesh and chums can (supposedly) do your job way cheaper (and the boss gets a bonus for reducing operational costs) is the day you realise what the problem could be.
doesn't matter how much surface area is road, you can install heat-exchanger systems in carparks and heat (and cool) buildings directly from their own carparking.
That said, a study has said that if 15% of Holland's had such a system installed, it would produce more energy that all the power utilities do, combined. It also means that roads last longer as they wouldn't freeze so easily and therefore develop cracks and potholes, nor have to be covered with rock salt to de-ice them.
I'm not so convinced by that argument, even if it has some appeal.
What I think happens (as someone who's been around the industry for a few years now) is that you become less interested in the technology, and more interested in making things. ie, I can no longer get enthused about the current cool framework, or how easy the new language can make things. I do get excited about making the products that we sell to our customers though, and doing a good job of it. I guess I'm just maturing a bit and starting to do the job rather than playing with the toys.
The ideal is probably a good mix of ages, you want the older guys doing designs and architecture, coming up with the requirements and user stories, and the younger guys slapping together the code - which is really what they like. As long as management stops promoting the young guys into positions where they decide how things should be put together, then we'll keep on with rewrites and poor code that's oh-so-cool but oh-so-useless.
Or maybe I'm just spouting nonsense and the real industry is filled with all sorts of people in all sorts of roles, no matter what age they are :)
or you could watch TFV (the video) to find out how this is addressed.
you definitely don;t use the version number, unless you're running Microsoft software and want to wait for the 3rd release as that's always the one that works. Even then, MS has cottoned on to this and releases products with all kinds of arbitrary version numbers to confuse you into buying not-ready releases.
Or maybe its because if you charged a fee to use the service, you'd have to increase the price to account for the servicing overhead - either an attendant, or an automated ticket system with cut-off timers and all the associated electronics.
Instead its better to charge once via taxes or grants and then allow useage for free. More people will use it and the cost of providing the service will be much reduced.
ah no. Its not about the 'bean counters' as they do a very good job counting beans and distributing them about - every business needs a good accounts department. There's also a lot to be said about running a business well, ensuring things like your production costs don't swamp the business and there's enough left in the pot to handle some lean years when you have the usual troughs in sales.
No, the problem is the 'management' who only count the beans they can get their hands on to the detriment of everything else. Where a focus is on short-term management of the numbers geared specifically for their own benefit, you know - "maximising profit" to get a better bonus even though it means laying off half the workforce; where product quality is secondary to end-quarter results even if it means releasing dangerous products as long as the current target is met, making the bonus payments flow in.
Most MBAs last 2 years at a company before moving on to destroy another one. Take a look at Nokia for the perfect example. Elop .. couldn't hack it anywhere for more than 2 years, and now is screwing Nokia and expects to gain a huge merger bonus (possibly when MS buys Nokia in a couple of years).
there are many tools that produce better software quality, btu they all seem to be up-front, and require a large amount of programmer time. This is probably because they are produced by programmers for programmers.
so test-driven-development is very fashionable at the moment, even though it doesn't really work well with legacy code and can take an amazing amount of time to set up for new; similarly code reviews are great, but require lots of time for a (presumably) better coder to check what you did is ok (as a cursory look through to spot the glaringly obvious problems isn't too much use).
So why do we spend so much programmer time checking and rechecking, when we can test the system like we used to in the old days. Not only can you get dedicated testers (who have fresh eyes on the problem), but they test all the other aspects that code review and unit test would miss.
I know there are places where unit tests are very good - regression testing a library for example, and code reviews are good for the blindingly obvious errors, but too much emphasis are given to these for almost every part of software nowadays. For example, I read today (on stackoverflow) that someone decided to use TDD for his new project and wrote 50 tests per module and it took him ages to get 100% test coverage, and now he can't bring himself to write a new module because it takes so long and is so unproductive. The answers were generally of "you're writing too many tests, 80% coverage is really good", but then.. if you only unit test 80% of your system, you're going to have to 'system test' the whole thing anyway!
So, I think they have their place, but they're not magic bullets of software quality, no matter how much my boss (who's been reading these blogs on the internet again) thinks they will be.