In some places in Canada, your MP is more than a 500 km drive away. I am used to a rural perspective, having never lived in a major urban center. Obviously, presenting your letter in person is far better.:)
You raise some excellent points. However, what about when a drive fails and you need to rebuild the array? Do you want your bus saturated for hours while your CPU busily performs an XOR operation for each byte on each drive? I'd much rather have a dedicated chip on the RAID device to handle this, although the software RAID is an option if you keep your drives on a separate bus (some motherboards support such).
It's like any math or science: there are often several ways of doing something, each more suited to a different situation. Each tool is designed to do a small, related subset of tasks. For instance, grep is designed to find something in content (from a pipe or a file), where find is designed to search for files, so it's natural there will be some overlap when handling mutliple files.
Yeah, or sometimes mods will mod a funny post insightful to give the poster karma.
It's funny you should say that about mods though... I still have one point to use right now.
Yeah, I since removed the area code after his comment. I'm not sure how else to disguise a number from a harvester. Ideas?
Re:Code can't be too big, just badly designed
on
Too Darned Big to Test?
·
· Score: 2, Insightful
If a piece of code is too big to test exhaustively, it's time to refactor it into bits that can be.
Yeah, I told that to my boss about the product that my predecessors have been working on for years, without any test cases. Internally it's a convoluted entwined mess. I estimated about a man-year to break it down and build it up again, with exhaustive test cases of all the parts. He laughed at the idea, and didn't see the business benefit.
This is just an excuse for badly designed code bases.
So what do you do with them when you are handed them?
Start.
You don't have to completely refactor the code -- but there is no reason why you can't refactor parts as you work on them. That happens all the time in the Linux kernel for instance. I would imagine every component in the kernel has been rewritten at least twice -- but not once was the whole kernel replaced.
I've found bugs in OSS before. I've reported them, and they've been fixed. Remember that people don't have unlimited time, and that your itch itches less than their own. If you are unwilling to write the fix yourself, what real insentive to they have to scratch your itch first? Have you tried putting a bounty on the bug you want resolved, such as cash?
Complaining about bug-fixing in volunteer maintained software is like complaining that no one picks the litter up in front of your house.
Re:Shouldn't that be too bloated to test?
on
Too Darned Big to Test?
·
· Score: 4, Insightful
And that, my friend, is why software "engineering" is not engineering at all. I'm all for raising coding standards to engineering levels. The amount of time and headaches saved by such an effort would easily exceed thousands of lifetimes. It's silly that we still accept such shoddy workmanship.
Re:Shouldn't that be too bloated to test?
on
Too Darned Big to Test?
·
· Score: 4, Insightful
That's actually more the philosophy of Unix -- to do one thing, and to do it well -- and has been around for 30+ years. I'd say that philosophy is common in the OSS world for a few reasons: One, open-source encourages code & component reuse. Two, most OSS developers don't have time to write large projects on their own, and three, the free software movement started in the Unix domain, the source of this philosophy.
Open-sourcing a project will do little to nothing in regards to testing. First, there is often little to no insentive to attract open-source developers. Second, a poor design is a poor design, and those in charge are highly unlikely to through a working design out (two rare exceptions are Apple's move to Mac OS X and Microsoft's move to NT). Third, open-source developers frequently have no insentive to test -- testing is boring and labourous. And while the occasional person may fix the occasional bug, on the whole, opening the source a product for testing purposesly is almost always a fruitless exercise.
Shouldn't that be too darned bloated to test? It shouldn't be hard to test the individual subcomponents for functionality and at boundary conditions. Of course, you can't fully test something as complex as the system in the article. No reasonable sized program can ever be fully debugged -- the possibilities are too many to explore. However, it is possible to fully verify the smallest components, and build large components from them and fully verify those as well. Obviously, the complexity increases greatly with each new layer, but when one is working with fully verified components, any errors that occur must be in the local logic. Granted, this is much more labour intensive, but as long as each component follows precise specifications, it's more than feasible. I'm amazed that many prominent software projects still use largely monolithic testing...
Slashdot Mirror
Shit! I just did that! Yikes. Crazy. Hopefully it gets accepted ;)
Well no Frenchman will have to worry about that, as ä isn't in the French alphabet. *shhh*
But you have a valid point.
In some places in Canada, your MP is more than a 500 km drive away. I am used to a rural perspective, having never lived in a major urban center. Obviously, presenting your letter in person is far better. :)
If you don't know how to contact them, you can find them on this page. Remember that a written letter carries more weight than an email or a fax.
You raise some excellent points. However, what about when a drive fails and you need to rebuild the array? Do you want your bus saturated for hours while your CPU busily performs an XOR operation for each byte on each drive? I'd much rather have a dedicated chip on the RAID device to handle this, although the software RAID is an option if you keep your drives on a separate bus (some motherboards support such).
But 17 is legal in Canada. No wonder why Canada is so popular on Slashdot.
I notice your stats don't list Konqueror -- is it really that rarely used? I love it... it's by far my favourite browser.
It's like any math or science: there are often several ways of doing something, each more suited to a different situation. Each tool is designed to do a small, related subset of tasks. For instance, grep is designed to find something in content (from a pipe or a file), where find is designed to search for files, so it's natural there will be some overlap when handling mutliple files.
That's brilliant! I shall implement that today...
You're not the first person to say that lol
Yeah, or sometimes mods will mod a funny post insightful to give the poster karma. It's funny you should say that about mods though... I still have one point to use right now.
"It certainly will not apply to the casual seller on eBay, but might apply to anyone who sells a lot."
So that means I can sell individual items, but not a lot of them?
Well that post made me laugh, and the skeletal structure in my arms is perfectly fine ;)
Then why are people modding it up as Insightful instead of Funny? The case for sarcasm is weak.
But that would double the number of images on the page! *laugh*
Perhaps I can encode it. I think I'll ambiguated it with some HTML comments for now.
It seemed more flamebaitish to me.
Yeah, I since removed the area code after his comment. I'm not sure how else to disguise a number from a harvester. Ideas?
Start.
You don't have to completely refactor the code -- but there is no reason why you can't refactor parts as you work on them. That happens all the time in the Linux kernel for instance. I would imagine every component in the kernel has been rewritten at least twice -- but not once was the whole kernel replaced.
Yeah, I need coffee or something. That's what I get for staying up until 5 a.m. I spoted a couple other errors in that post, too.
And that email addy to my cell is simply a forwarding address.
I've found bugs in OSS before. I've reported them, and they've been fixed. Remember that people don't have unlimited time, and that your itch itches less than their own. If you are unwilling to write the fix yourself, what real insentive to they have to scratch your itch first? Have you tried putting a bounty on the bug you want resolved, such as cash?
Complaining about bug-fixing in volunteer maintained software is like complaining that no one picks the litter up in front of your house.
And that, my friend, is why software "engineering" is not engineering at all. I'm all for raising coding standards to engineering levels. The amount of time and headaches saved by such an effort would easily exceed thousands of lifetimes. It's silly that we still accept such shoddy workmanship.
That's actually more the philosophy of Unix -- to do one thing, and to do it well -- and has been around for 30+ years. I'd say that philosophy is common in the OSS world for a few reasons: One, open-source encourages code & component reuse. Two, most OSS developers don't have time to write large projects on their own, and three, the free software movement started in the Unix domain, the source of this philosophy.
Open-sourcing a project will do little to nothing in regards to testing. First, there is often little to no insentive to attract open-source developers. Second, a poor design is a poor design, and those in charge are highly unlikely to through a working design out (two rare exceptions are Apple's move to Mac OS X and Microsoft's move to NT). Third, open-source developers frequently have no insentive to test -- testing is boring and labourous. And while the occasional person may fix the occasional bug, on the whole, opening the source a product for testing purposesly is almost always a fruitless exercise.
Shouldn't that be too darned bloated to test? It shouldn't be hard to test the individual subcomponents for functionality and at boundary conditions. Of course, you can't fully test something as complex as the system in the article. No reasonable sized program can ever be fully debugged -- the possibilities are too many to explore. However, it is possible to fully verify the smallest components, and build large components from them and fully verify those as well. Obviously, the complexity increases greatly with each new layer, but when one is working with fully verified components, any errors that occur must be in the local logic. Granted, this is much more labour intensive, but as long as each component follows precise specifications, it's more than feasible. I'm amazed that many prominent software projects still use largely monolithic testing...
That's because I'm crippled, you insentive clod!