I may be wrong, but I think he was saying that by caching the output to disk, additional requests are served faster than compiled C code could dynamically generate the page.
Of course, the binary could also cache the page...
Well, you have to understand that Death is a unix geek from way back. Unfortunately due to a shipping glich he got one of Hell's windows machines by mistake. So naturally, these little goofs are going to pop up from time to time until they get it all worked out.
Actually the real problem with the Iomega drives is that most computers don't include them by default.
When DVD-ROM drives are available almost automatically, the DVD+/-R(W) drives become more tempting.
That's what happened with CDs. Even now CD's beat out all other media because they're more robust & you're more certain of finding a device capable of reading your disk.
Don't forget the most important part of a backup strategy: knowing you'll be able to read the backup.
I do agree about the economy of using IDE HD for backup, but I have to say it makes me nervous. It might be silly to feel this way now, but I still think of HD's as extremely fragile.
I've driven diesel vehicles which required the "glow plug" warm up. That isn't quite the same thing. The glow plug warm up was required for the engine to start. If my DVD player requires a few seconds to get started, I don't really complain (it actually does - about 2-4 seconds from power-on before it begins displaying anything).
A better analogy would be if car manufacturers rigged the cars to display a 10 second message about the laws governing the use of the vehicle and the penalties for violating those laws.
I think that would really, REALLY, irritate people. I know I have to obey the law. I don't need to be reminded of it every time I start my car. Although, I have to admit that I encounter quite a few people who could use a reminder
I know I can't distribute copies of a DVD. I don't need to be reminded of it every time I start watching a movie.
My father-in-law was a USPS employee, and although he made it clear that certain nonsense was strictly prohibited, there was still plenty of nonsense going on: water gun battles, rubber band battles, etc. I would occasionally get magazines with notes from my future father-in-law slipped into them.
It didn't sound like a particularly stressful existence.
Also, the poor design allowed them to play another trick. Just by checking a student's status (accepted/rejected) before the student did they could trick the student into thinking they were rejected even if they were accepted.
You won't be able to identify the address range because they will be hiring contracters (ie, crackers) to do the work for them. I doubt the MPAA has that many crackers on the payroll. The people they hire will probably be smart enough to do what crackers do (use different hosts, try to hide their location, etc.)
What if the reason for the power failure is that someone tripped over the cord running from the UPS to the PC & pulled it out, or if the Power supply in the PC failed? How about if you were in the computer room & saw smoke & fire pouring out of the server? How about if the UPS failed?
There are cases where a UPS won't prevent an "unexpected downtime". In these cases, it might be helpful if the drives were able to finish their last write on their own power. It might give you something to boot after you correct the problem.
I found the flaw in your reasoning. Don't look for a way for it to make sense. It doesn't. It shouldn't. It can't. If you start thinking that it is starting to make sense, start worrying.
You're still getting it wrong. This isn't about *reviewing* code. It is about how you develop the code in the first place. You start with loose definitions of the various components of the application, then you solidify the requirements for each component. After that you produce rough pseudo code to describe the algorithm. Then you begin to write out the actual code. Each of these steps would be reviewed and approved before you could move on. Each component would be small and simple enough to be relatively bug free, and the definitions of the requirements for the component should control the interactions with all the other components being developed.
> That's not so black and white as it should be, > at the most basic level, people don't know what > they really want until after the product is > delievered. Something sounds like a great > feature, and all the users like it on paper, > and then they play with the prototype and > demand it be removed.
While that is true, I think calling that a bug really stretches the definition of bug. Not that the users in question would admit it, but it is really a specification change.
In a situation where a contract has been signed based on a well defined specification, not only would the users have to pay the agreed on cost of developing the feature, they'd also have to pay the cost to have it removed...as they should.
Unfortunately, I live in the same world you live in. I'd like to live in a world where the effort went into avoiding the bugs rather than finding them after the fact, but I am also faced with unreasonable demands that force inferior code out the door.
> Too bad there's no such thing as a spell > checker built into most compilers. Just simple, > as you type, error notification would be cute.
Even that is too late. By the time you start typing, every line of the program should already be set in stone. Every line of code should have been evaluated and approved long before it was typed. It doesn't require a "perfect world". It could happen in this one (& does in rare cases). However, you have to believe that it is possible, and then you have to choose to do it.
> Not all bugs are code, many 'bugs' are exactly > what the designer intended... but the users > hate it.
Again, this is a failure in the planning & design. Why would the designers plan & code something that the users don't want (or won't use, or can't use, etc.). This is one of the bigger problems I've seen. People design applications without finding out what the users want it to do. Example:
Radiology image viewing workstation. Vender designs the application to display the images with a wide black border around the image. Radiologists don't want to waste the screen. They want to display the image as large as they can, with as much detail as the hardware can display. However, it does look prettier with the border;-)
Sorry, I couldn't help pointing it out in this case.
But you made the point for me. Put the thinking *before* the typing and the bugs should be *greatly* reduced. True, I did exaggerate. You won't avoid all bugs, but I still say that you'll spend a lot more finding & correcting bugs than you will if you invested more in the planning. Particularly if you factor in the bugs you *won't* find.
If you are still finding tons of bugs after you did all your planning & design, you may not have done enough planning & design. Perhaps the problem is not carefully sticking with the design or not having a good process for changing the design when the changes are unavoidable.
Slashdot Mirror
Yes you are.
I may be wrong, but I think he was saying that by caching the output to disk, additional requests are served faster than compiled C code could dynamically generate the page.
Of course, the binary could also cache the page...
Well, you have to understand that Death is a unix geek from way back. Unfortunately due to a shipping glich he got one of Hell's windows machines by mistake. So naturally, these little goofs are going to pop up from time to time until they get it all worked out.
Death: "Dammit, WHERE'S VI!?!?!?"
For those geeks & nerds who aren't aware, the Schoolhouse Rock 30th anniversary DVD was released on July 27th.
Really cool. I haven't seen some of them in years.
If you don't know why three is the magic number, you probably don't know Schoolhouse Rock.
I thought three was the magic number.
Very long copper wire.
Actually the real problem with the Iomega drives is that most computers don't include them by default.
When DVD-ROM drives are available almost automatically, the DVD+/-R(W) drives become more tempting.
That's what happened with CDs. Even now CD's beat out all other media because they're more robust & you're more certain of finding a device capable of reading your disk.
Don't forget the most important part of a backup strategy: knowing you'll be able to read the backup.
I do agree about the economy of using IDE HD for backup, but I have to say it makes me nervous. It might be silly to feel this way now, but I still think of HD's as extremely fragile.
I've driven diesel vehicles which required the "glow plug" warm up. That isn't quite the same thing. The glow plug warm up was required for the engine to start. If my DVD player requires a few seconds to get started, I don't really complain (it actually does - about 2-4 seconds from power-on before it begins displaying anything).
A better analogy would be if car manufacturers rigged the cars to display a 10 second message about the laws governing the use of the vehicle and the penalties for violating those laws.
I think that would really, REALLY, irritate people. I know I have to obey the law. I don't need to be reminded of it every time I start my car. Although, I have to admit that I encounter quite a few people who could use a reminder
I know I can't distribute copies of a DVD. I don't need to be reminded of it every time I start watching a movie.
My father-in-law was a USPS employee, and although he made it clear that certain nonsense was strictly prohibited, there was still plenty of nonsense going on: water gun battles, rubber band battles, etc. I would occasionally get magazines with notes from my future father-in-law slipped into them.
It didn't sound like a particularly stressful existence.
> No one reallly knows except Escher, who's
> unlikely this late in the game the disclose it
> (ie. he's passed on).
Hey, it never hurts to ask. I lit a candle. Now, everybody hold hands, close your eye's and concentrate.
Also, the poor design allowed them to play another trick. Just by checking a student's status (accepted/rejected) before the student did they could trick the student into thinking they were rejected even if they were accepted.
> iptables -A INPUT -s x.y.z.0/24 -j DROP
Just so you know, that would almost have to be:
iptables -A INPUT -s 0.0.0.0/0 -j DROP
You won't be able to identify the address range because they will be hiring contracters (ie, crackers) to do the work for them. I doubt the MPAA has that many crackers on the payroll. The people they hire will probably be smart enough to do what crackers do (use different hosts, try to hide their location, etc.)
What are you bitching about? We gave you a great little car.
What if the reason for the power failure is that someone tripped over the cord running from the UPS to the PC & pulled it out, or if the Power supply in the PC failed? How about if you were in the computer room & saw smoke & fire pouring out of the server? How about if the UPS failed?
There are cases where a UPS won't prevent an "unexpected downtime". In these cases, it might be helpful if the drives were able to finish their last write on their own power. It might give you something to boot after you correct the problem.
I hate to think of what you're going to have to go through to teach her how to install Linux.
use /bin/mail ;-)
...or even pine...
Hey, man, don't interrupt our mindless rant. We were on a roll.
Ok, now I'm curious. Whose Dad would win? Does anyone have any stats on the Dads?
I can ignore all of those but one. While our boy Ben was in France begging for help with our revolution, France was still a monarchy.
> but this makes most sense to me.
I found the flaw in your reasoning. Don't look for a way for it to make sense. It doesn't. It shouldn't. It can't. If you start thinking that it is starting to make sense, start worrying.
Yeah, but us USAmericans just like sticking it to the French. ;-)
You're still getting it wrong. This isn't about *reviewing* code. It is about how you develop the code in the first place. You start with loose definitions of the various components of the application, then you solidify the requirements for each component. After that you produce rough pseudo code to describe the algorithm. Then you begin to write out the actual code. Each of these steps would be reviewed and approved before you could move on. Each component would be small and simple enough to be relatively bug free, and the definitions of the requirements for the component should control the interactions with all the other components being developed.
> That's not so black and white as it should be,
> at the most basic level, people don't know what
> they really want until after the product is
> delievered. Something sounds like a great
> feature, and all the users like it on paper,
> and then they play with the prototype and
> demand it be removed.
While that is true, I think calling that a bug really stretches the definition of bug. Not that the users in question would admit it, but it is really a specification change.
In a situation where a contract has been signed based on a well defined specification, not only would the users have to pay the agreed on cost of developing the feature, they'd also have to pay the cost to have it removed...as they should.
Unfortunately, I live in the same world you live in. I'd like to live in a world where the effort went into avoiding the bugs rather than finding them after the fact, but I am also faced with unreasonable demands that force inferior code out the door.
;-)
> Too bad there's no such thing as a spell
> checker built into most compilers. Just simple,
> as you type, error notification would be cute.
Even that is too late. By the time you start typing, every line of the program should already be set in stone. Every line of code should have been evaluated and approved long before it was typed. It doesn't require a "perfect world". It could happen in this one (& does in rare cases). However, you have to believe that it is possible, and then you have to choose to do it.
> Not all bugs are code, many 'bugs' are exactly
> what the designer intended... but the users
> hate it.
Again, this is a failure in the planning & design. Why would the designers plan & code something that the users don't want (or won't use, or can't use, etc.). This is one of the bigger problems I've seen. People design applications without finding out what the users want it to do. Example:
Radiology image viewing workstation. Vender designs the application to display the images with a wide black border around the image. Radiologists don't want to waste the screen. They want to display the image as large as they can, with as much detail as the hardware can display. However, it does look prettier with the border
> So your doing it on purpose?
^^^^
"you're" not "your".
Sorry, I couldn't help pointing it out in this case.
But you made the point for me. Put the thinking *before* the typing and the bugs should be *greatly* reduced. True, I did exaggerate. You won't avoid all bugs, but I still say that you'll spend a lot more finding & correcting bugs than you will if you invested more in the planning. Particularly if you factor in the bugs you *won't* find.
If you are still finding tons of bugs after you did all your planning & design, you may not have done enough planning & design. Perhaps the problem is not carefully sticking with the design or not having a good process for changing the design when the changes are unavoidable.