With reengineering this could be a beautiful thing to put together entirely hands-off. As it is, the design is only amenable to manual assembly. As you imply, it'd require different approaches to design of various parts to get good yields with automated assembly. I'd love it if a couple iPhones down the road there was a device where nobody touches anything once it is loaded up into assembly cells -- all the way to final boxing.
Ah, but you see, in first world you automate a lot of such production because it's cheaper. The setup is costlier, but repeatability goes up vs. unpredictableness of tired labor force, and longer term you can actually make it cheaper than in asia. Once your setup is done, adding robot cells to the line only costs you amortization -- capital equipment can be leased and scaled with demand. Sure Foxconn can set up stuff in a couple of weeks because they have next to no programmable machinery outside of various test cells, it's mostly all manual labor with some custom but simple tools. In the U.S., if you get a bunch of dedicated manufacturing people, they could set up automation about just as quick, given proper resources.
Whoever thought up this "functionality" should be made to pay for all the lost data. I kid you not. There's stupid, then there's this "behavior", amounting IMHO to willful destruction of user data.
I agree but the quality of the code wasn't my point. I argued that no matter what the quality of the code was, the personal troubles of the chief architect don't figure in the equation if one is to stay rational. According to you the code is essentially shit, and I'd agree there, but, again, that's beside the point entirely. The idea that filesystem data stays uncorrupted is a pipe dream of course unless you get an error correcting block driver layer. It's silly to assume such when, demonstrably, no such layer was in common use on Linux when reiser4 was being developed. Heck, no such layer is in common use on Linux even now -- lvm doesn't have such a plugin, right?
There is nothing tricky about handling "unsolicited power cycles" except that people with no clue about software engineering are dabbling with systems that are de facto critical for business continuity, whether it's a mom-and-pop shop, or a big operation with fast databases. The fundamental issue is with the qualifications of people who specify, design and implement the firmware, or more importantly, their management, or that management's management. I don't care if the problem is all the way up to the board of directors, as it may well be. Alas, that's all there's to it. It's a people problem. Demonstrably, people who know their shit can make data stores that survive random restarts just fine. See sqlite, for example.
The biggest deal is that the progress is the enemy of quality here. Well engineered software (following a tried and true process like UL 1998) takes time to be specified, designed, implemented and validated. All SSD drive vendors would be well advised to have a hardware abstraction layer that tracks changes in hardware, but core function of data management should be engineered and treated like a long lifetime safety critical software component.
The major problem, I think, is that hard drives of any sort have their costs cut to the bone. Thus spinning platter hard drives store firmware on the platter and not in flash, only simplified loader firmware is stored in a boot (eep)rom somewhere. This demonstrates that same goes for SSDs, apparently. The BIOS doesn't detect them because with dead data storage flash, they can't even boot up properly the controller. There is no reason whatsoever for an SSD to slow down at all when faced with uncorrectable read errors from the data flash, or to appear unresponsive because of that. It simply needs to fail all the data reads and that's it.
I don't know if I didn't get the point across or if you're just purposely obtuse, but human "nature", as you put it, tends to be a self-fulfilling prophecy. It's up to oneself to stay rational. The "name tainting the work" may surely be how you initially feel, but man, if you don't take it past that and realize it's a somewhat childish approach, then I'm scared of you.
Yeah, it's demonstrably human nature to murder and rape, obviously. That's where reason comes in. If you can't reason around your instincts so to speak, you're not quite in control of your emotions, and I'd find it somewhat, uh, problematic let's say.
Databases obviously handle it just fine, so the theoretical impossibility isn't there, and demonstrably so. The question is whether existing filesystem APIs are up for the job. I think they aren't. Passing things back and forth one file name or one file descriptor at a time is quite wasteful. Syscalls aren't free.
Either it's a decent codebase or it isn't. If it is, there's no point in wasting all that labor just because one of the authors is a murderer. It's like if you wanted to ban every murderer's memoir from distribution. It's a silly approach IMHO. Don't anthropomorphize the code. Your admission "I'd rather let him watch his brainchild die" is not a rational response at all. Personally, I'd much rather exploit the fruits of his labor if at all possible. That's a bit more productive, don't you think?
No. I only need to leave her long enough in care of our university medical center and they'd gladly do the job, and bill me for it, too (I'm serious). If you or anyone honestly thinks of wanting to murder the spouse, it's time to get a divorce. Seriously. And do some lessons learned analysis to make sure you don't make the same mistake if there is to be a second time.
With my driving the bushings last only a couple of years anyway. Somehow we both manage to kill our balljoints in under 3 years, and that's stock quality parts. On my wife's car the endlinks last under a year, and they only lasted a couple months longer before I beefed up her swaybars:( I'll have to check into that o-ring theory, I don't have my shocks but I think I'll swap my wife's and give them a go with a disc cutter on the mill to see what's inside.
We hate mushy rides, she has upgraded swaybars, I replaced the strut bar bushings with solid aluminum, she has new front strut seats/bearings since the originals were gone; I didn't bother doing the struts at the time since there was nothing visually wrong with them and the handling was on par with the few other cars of same model year I had access to. On my car about 10k miles ago I replaced everything in suspension that was replaceable, all the way to inner tie rods.
I've changed them all on my car at 220k and it only made difference in one corner where the factory shock was leaking. Otherwise the handling differences were hard to notice, even when I decided to take on some potholes a bit fast. The other three looked like new, apart from being dusty. There is no reason to believe that internally they'd be unduly worn out. It's a closed system, like an automatic transmission. Shocks fail when the external seal fails and dust starts getting in, and when fluid leaks out. I have a 6DOF inertial logger so if I'd fall to your persuasion, I'll first have a go at a preset speed over my favorite pothole stretch both before and after and see if there is any quantitative difference. Yes, I'll go over that stretch a couple of times to see what the variability is before changing anything.
You have had one car that had another unfixed problem (stalling) at slow speeds and your complaint was that it was hard to drive it off the road when it was stalled. Well, guess what, most drivers would be probably, and rightly so, concerned with not hitting whoever is in front of them as brake assist fades away and would simply stop in their lane and deal with pushing the car off the road later. Your reaction time to start getting off the road while limping around is immaterial, it's only a convenience. Nothing to do with safety I'd think. You have to safely stop while maintaining lane control as appropriate. That's all the car is supposed to help you with, and I don't see a problem there. It was a problem for you only because your habits were not very safe. If you haven't had that one problematic Honda, I wouldn't even be reading your post, right? Or is there something else you're not telling us?
Or, so then tiny shards of passivated silicone will be better tolerated, then? And whatever electrode surfaces are exposed for those things to harvest power will obviously not be a problem either? No, this is not a false dichotomy. Sure everything has to be addressed, but let's perhaps not get overexcited by solving the smallest part of the problem by volume and surface area, by far.
US legislation sets out requirements for current model year cars that are marketed here. For 2012 models, not only traction control is required, but stability augmentation is required as well. This all doesn't mean much because in practice traction, ABS and stability is done in a common hydraulic actuator box that can modulate and apply brakes individually under computer control. Traction control also cuts off fuel (and moves back throttle in throttle-by-wire cars), but that comes at no extra hardware cost. Addition of stability control isn't very costly, sure the hydraulic actuator system needs a few more valves IIRC, and a beefier pump, but that's about it. Nothing huge.
Besides, plenty of cars do not need new shocks after $100k. My wife's has 200k and still doesn't need new shocks and handles great. It needed a new transmission, though:)
Slashdot Mirror
With reengineering this could be a beautiful thing to put together entirely hands-off. As it is, the design is only amenable to manual assembly. As you imply, it'd require different approaches to design of various parts to get good yields with automated assembly. I'd love it if a couple iPhones down the road there was a device where nobody touches anything once it is loaded up into assembly cells -- all the way to final boxing.
Ah, but you see, in first world you automate a lot of such production because it's cheaper. The setup is costlier, but repeatability goes up vs. unpredictableness of tired labor force, and longer term you can actually make it cheaper than in asia. Once your setup is done, adding robot cells to the line only costs you amortization -- capital equipment can be leased and scaled with demand. Sure Foxconn can set up stuff in a couple of weeks because they have next to no programmable machinery outside of various test cells, it's mostly all manual labor with some custom but simple tools. In the U.S., if you get a bunch of dedicated manufacturing people, they could set up automation about just as quick, given proper resources.
LOL. Care to name this mythical manufacturing giant, then?
My bad then, please accept sincere apologies :)
Whoever thought up this "functionality" should be made to pay for all the lost data. I kid you not. There's stupid, then there's this "behavior", amounting IMHO to willful destruction of user data.
I agree but the quality of the code wasn't my point. I argued that no matter what the quality of the code was, the personal troubles of the chief architect don't figure in the equation if one is to stay rational. According to you the code is essentially shit, and I'd agree there, but, again, that's beside the point entirely. The idea that filesystem data stays uncorrupted is a pipe dream of course unless you get an error correcting block driver layer. It's silly to assume such when, demonstrably, no such layer was in common use on Linux when reiser4 was being developed. Heck, no such layer is in common use on Linux even now -- lvm doesn't have such a plugin, right?
There is nothing tricky about handling "unsolicited power cycles" except that people with no clue about software engineering are dabbling with systems that are de facto critical for business continuity, whether it's a mom-and-pop shop, or a big operation with fast databases. The fundamental issue is with the qualifications of people who specify, design and implement the firmware, or more importantly, their management, or that management's management. I don't care if the problem is all the way up to the board of directors, as it may well be. Alas, that's all there's to it. It's a people problem. Demonstrably, people who know their shit can make data stores that survive random restarts just fine. See sqlite, for example.
The biggest deal is that the progress is the enemy of quality here. Well engineered software (following a tried and true process like UL 1998) takes time to be specified, designed, implemented and validated. All SSD drive vendors would be well advised to have a hardware abstraction layer that tracks changes in hardware, but core function of data management should be engineered and treated like a long lifetime safety critical software component.
The major problem, I think, is that hard drives of any sort have their costs cut to the bone. Thus spinning platter hard drives store firmware on the platter and not in flash, only simplified loader firmware is stored in a boot (eep)rom somewhere. This demonstrates that same goes for SSDs, apparently. The BIOS doesn't detect them because with dead data storage flash, they can't even boot up properly the controller. There is no reason whatsoever for an SSD to slow down at all when faced with uncorrectable read errors from the data flash, or to appear unresponsive because of that. It simply needs to fail all the data reads and that's it.
I don't know if I didn't get the point across or if you're just purposely obtuse, but human "nature", as you put it, tends to be a self-fulfilling prophecy. It's up to oneself to stay rational. The "name tainting the work" may surely be how you initially feel, but man, if you don't take it past that and realize it's a somewhat childish approach, then I'm scared of you.
Yeah, it's demonstrably human nature to murder and rape, obviously. That's where reason comes in. If you can't reason around your instincts so to speak, you're not quite in control of your emotions, and I'd find it somewhat, uh, problematic let's say.
That's some batshit crazy stuff indeed :(
Nobody can afford not having a backup solution, mind you.
Databases obviously handle it just fine, so the theoretical impossibility isn't there, and demonstrably so. The question is whether existing filesystem APIs are up for the job. I think they aren't. Passing things back and forth one file name or one file descriptor at a time is quite wasteful. Syscalls aren't free.
Either it's a decent codebase or it isn't. If it is, there's no point in wasting all that labor just because one of the authors is a murderer. It's like if you wanted to ban every murderer's memoir from distribution. It's a silly approach IMHO. Don't anthropomorphize the code. Your admission "I'd rather let him watch his brainchild die" is not a rational response at all. Personally, I'd much rather exploit the fruits of his labor if at all possible. That's a bit more productive, don't you think?
At least someone who gets how things are supposed to be :)
No. I only need to leave her long enough in care of our university medical center and they'd gladly do the job, and bill me for it, too (I'm serious). If you or anyone honestly thinks of wanting to murder the spouse, it's time to get a divorce. Seriously. And do some lessons learned analysis to make sure you don't make the same mistake if there is to be a second time.
With my driving the bushings last only a couple of years anyway. Somehow we both manage to kill our balljoints in under 3 years, and that's stock quality parts. On my wife's car the endlinks last under a year, and they only lasted a couple months longer before I beefed up her swaybars :( I'll have to check into that o-ring theory, I don't have my shocks but I think I'll swap my wife's and give them a go with a disc cutter on the mill to see what's inside.
We hate mushy rides, she has upgraded swaybars, I replaced the strut bar bushings with solid aluminum, she has new front strut seats/bearings since the originals were gone; I didn't bother doing the struts at the time since there was nothing visually wrong with them and the handling was on par with the few other cars of same model year I had access to. On my car about 10k miles ago I replaced everything in suspension that was replaceable, all the way to inner tie rods.
I've changed them all on my car at 220k and it only made difference in one corner where the factory shock was leaking. Otherwise the handling differences were hard to notice, even when I decided to take on some potholes a bit fast. The other three looked like new, apart from being dusty. There is no reason to believe that internally they'd be unduly worn out. It's a closed system, like an automatic transmission. Shocks fail when the external seal fails and dust starts getting in, and when fluid leaks out. I have a 6DOF inertial logger so if I'd fall to your persuasion, I'll first have a go at a preset speed over my favorite pothole stretch both before and after and see if there is any quantitative difference. Yes, I'll go over that stretch a couple of times to see what the variability is before changing anything.
You have had one car that had another unfixed problem (stalling) at slow speeds and your complaint was that it was hard to drive it off the road when it was stalled. Well, guess what, most drivers would be probably, and rightly so, concerned with not hitting whoever is in front of them as brake assist fades away and would simply stop in their lane and deal with pushing the car off the road later. Your reaction time to start getting off the road while limping around is immaterial, it's only a convenience. Nothing to do with safety I'd think. You have to safely stop while maintaining lane control as appropriate. That's all the car is supposed to help you with, and I don't see a problem there. It was a problem for you only because your habits were not very safe. If you haven't had that one problematic Honda, I wouldn't even be reading your post, right? Or is there something else you're not telling us?
Or, so then tiny shards of passivated silicone will be better tolerated, then? And whatever electrode surfaces are exposed for those things to harvest power will obviously not be a problem either? No, this is not a false dichotomy. Sure everything has to be addressed, but let's perhaps not get overexcited by solving the smallest part of the problem by volume and surface area, by far.
US legislation sets out requirements for current model year cars that are marketed here. For 2012 models, not only traction control is required, but stability augmentation is required as well. This all doesn't mean much because in practice traction, ABS and stability is done in a common hydraulic actuator box that can modulate and apply brakes individually under computer control. Traction control also cuts off fuel (and moves back throttle in throttle-by-wire cars), but that comes at no extra hardware cost. Addition of stability control isn't very costly, sure the hydraulic actuator system needs a few more valves IIRC, and a beefier pump, but that's about it. Nothing huge.
Besides, plenty of cars do not need new shocks after $100k. My wife's has 200k and still doesn't need new shocks and handles great. It needed a new transmission, though :)
Assuming you do it yourself, it should all fit under $750, give or take, for a common model.
Ice Road truckers don't drive in congested city traffic you bozo.