All the same, I do prefer emacs. Autocomplete is kind of nice, but it's a hack that isn't necessary if your code is written well.
Talk about rationalizing after the fact! If Emacs had autocomplete, you'd be touting it as a must-have. A hack? How so? Encourages people to write code that relies on it? Are you kidding?
Autocomplete is a great tool that helps you write code faster, especially on large projects where you may be unfamiliar with APIs (for example) written by other developers.
I think that a certain degree of insulation from 'corporate' or 'other management' or the 'insane seesaw that is discussions with senior management about changing priorities and potential changes to already ongoing projects' is good.
My experience, having taken over teams where there was no insulation from these (normal) vagaries of software development projects, is that once some insulation, and the resulting focus and direction was in place, productivity and job satisfaction was up by orders of magnitude.
If individual contributors are never sure what's next, and even if the thing they are working on is the right thing, it's fair to say that you're very likely to see very low productivity.
This obviously doesn't mean that your ideas about the 'life of every department' aren't valid, just that they need to be tempered by an appropriate level of focus, and, yes, insulation.
No, I'm afraid you're mistaken. Did you read your own link? I did read the link. I will admit that my initial statement about TM and differential backups could be construed as saying that differential backups mean what you call 'delta-storage'. It doesn't. It means what the link refers to. I'm sorry this caused consternation for you.
I believe you are thinking of a delta-type backup (like rsync). I also believe that if you look at commercial backup solutions, you will find that a majority of them do NOT do this kind of thing. You're usually on your own hacking together rsync scripts, or you're dealing with some kind of file syncing product and not an standard backup solution. Actually, I was really trying to comment on a problem with Time Machine.:-)
But to respond to your point about what's available out there, I have been participating in the Box Backup project for the last few years, and that performs file-delta backups, and also has a host of other nice features.
Ummm...actually in the context of backup strategies, that is typically EXACTLY what differential backup means. Not to say it excludes the possibility of delta-only storage, but that is most certainly *not* implied. I think you're thinking of incremental backups, not differential. TM performs incremental backups, not differential. Here's an explanation of the difference.
It's not broken, so don't ever expect it to be "fixed". When designing the backup system, they chose to use fewer real-time computing resources so that it was essentially invisible to the users (and thus wouldn't get turned off by everyone for "slowing down the computer") and make restoration trivially simple and fast, at the expense of disk space. You can disagree with their choices, but they're the same tradeoffs every backup system designer has to make. Eh, my complaint really was not about differential backups, which I agree with you are not a feasible way to go for them.
I was really asking about the problem I outlined where short-lived files are not retained in daily/weekly backups. That to me is not acceptable.
It is not differential by any stretch. Backing up the entire file when it changes does not qualify as differential.
What I want to know is if Apple fixed the glaring hole where files that are (relatively) short lived disappear when a particular backup is 'promoted' for (eg) hourly to daily. If a file that was created after the last daily backup but deleted before this one is promoted, you're SOL.
Some backup...:-(
I suspect this is not fixed, but I don't know. Anyone?
Uh, you're missing the point... The GP was saying that he thought the 'emotional' issues (flag-burning, gay marriage, etc.) were less important to base your voting on than the important ones: health care, economy, Iraq, and the environment; things that a federal government needs to do something about.
This is what I did. I taught 2 semesters of Java (intro and 'advanced'). during the 'intro' semester I did not use any IDE. I wanted to be sure that the students understood the basics of how to develop: edit, compile test, rinse, repeat. IDEs are not conducive to this. Too many mistakes that are excellent learning opportunities are missed in an IDE. Understanding that class/variable naming makes a difference for the understanding of your program, and that you need to think about what you call your idetifiers; Actually running the compiler to generate (in this case) the byte code that will be run. An IDE glosses that over for you. There are many more things that make the non-IDE method good for the intro-type classes.
When I taught the same people the 'advanced' class, I started them out with an IDE. Just the fact that they realized how many things the IDE did for them was a major learning experience. Catching syntax errors, color coding, compiling, documentation links, etc. IDEs do, however, nudge you towards a particular way of programming, which may not be desirable. Syntax errors are caught immediately, which when you're writing a new piece of code with new variables, etc. becomes a distraction. You feel like you have to fix the syntax error before you can continue with your new code. Especially when you're just learning, this will make you lose your train of thought, and can get annoying pretty fast.
Anyway, bottom line: I am in favor of using the non-IDE approach for getting started with programming, and then graduating to an IDE. Not because "I had it bad, so you have to as well", but I really think there's merit in learning the basics of it, to gain a more complete understanding of the process of development.
The HD Tivos actually get their guide data over the satellite feed (they're all DirecTV units) and don't actually need a phone line, to my knowledge. I might be out of the loop on this, however.
Yeah, they do need the phone line. Not to get the guide, but to make PPV purchases. If you don't do that (PPV), you might be OK without a POTS line, except for during setup.
I'm glad to hear that you are capable of sending more than 5 messages/hour.;-)
WRT the lists, etc. I was actually thinking of counting the incoming connections to the MTA (ie. you connecting to sendmail), not the outgoing (sendmail connecting to the world). Of course this is not fool proof, and perhaps 5 is not the right number, and maybe an hour is not the right time unit. Maybe it should be more like 'if you send more than 5 messages/hr for a period of 12 hours from your PC, you will be blocked'.
Hmmm... Does anyone have more details on that number? Where did you see this?
I'd really like some hard data so the problem can be prioritized. All I've seen in this discussion so far, is "Most" or "almost all", or (as above) "80+%". No sources for this info, or explanation about it.
Sigh!
BTW, I'm not being an apologist for botnets or anything, but I'd really like to know how big this problem is, and I can't seem to get any actual dta on this. Someone must have done some crunching of logs, to get some idea of the extent of the problem...
Wonderful solultion. So if people would just stop crashing cars we could get rid of all the safety features. If nations could just get along we could save billions in military spending.
RTFA! While Carl seems to rip on most established techniques for stopping spam, that's only because they don't work very well. If they did, why would huge masses of people still be complaining about loads of spam in their inboxes? He also does say that many of the techniques should still be used, but that they won't solve the problem. Quoth: They are a band-aid...
...nearly all spam emails nowadays aren't sent over open relays but over 0wn3ed i.e. trojaned PCs...
Really?
How do you know this? I'd love to see the stats that support this. I'm not trying to be facetious, I'd really like to get hard data like that.
I agree 100% with Carl. Forcing admins to get a clue about the state of their outbound mail is key. And as he says, there are ways to control all this stuff. Even trojaned PCs can be controlled, by limiting the number of outbound messages from that machine to something reasonably low (like 5/hour). If the machine goes over that, you have (most likely) found a trojaned machine.
Of course, there are going to be significant costs to this approach in the beginning, because of the (presumably) large number of pwned PCs in the world. However, the ongoing cost of keeping up with spam complaints, storage requirements, and bandwidth costs should exceed the price of handling a large load of complaints over a relatively short term (giving a quick ROI), which all PHBs (including myself) like to use to sell it to higher-ups.
I don't know about the major supplier, but look at a country like Denmark. Over 20% of power in Denmark is produced by wind.
It's a matter of political will to get something like that through. That's why it won't work in the US, as long as we have oil-men running the country.
Sorta hate to say it, but Samba is probably your best bet. It works on all the platforms you mention (don't know about Mac OS 9, though), and is fairly painless to set up on XP and OS X, and IMO not too horrible to manage on Linux and others.
Slashdot Mirror
All the same, I do prefer emacs. Autocomplete is kind of nice, but it's a hack that isn't necessary if your code is written well.
Talk about rationalizing after the fact! If Emacs had autocomplete, you'd be touting it as a must-have. A hack? How so? Encourages people to write code that relies on it? Are you kidding?
Autocomplete is a great tool that helps you write code faster, especially on large projects where you may be unfamiliar with APIs (for example) written by other developers.
I think that a certain degree of insulation from 'corporate' or 'other management' or the 'insane seesaw that is discussions with senior management about changing priorities and potential changes to already ongoing projects' is good.
My experience, having taken over teams where there was no insulation from these (normal) vagaries of software development projects, is that once some insulation, and the resulting focus and direction was in place, productivity and job satisfaction was up by orders of magnitude.
If individual contributors are never sure what's next, and even if the thing they are working on is the right thing, it's fair to say that you're very likely to see very low productivity.
This obviously doesn't mean that your ideas about the 'life of every department' aren't valid, just that they need to be tempered by an appropriate level of focus, and, yes, insulation.
But to respond to your point about what's available out there, I have been participating in the Box Backup project for the last few years, and that performs file-delta backups, and also has a host of other nice features.
I was really asking about the problem I outlined where short-lived files are not retained in daily/weekly backups. That to me is not acceptable.
It is not differential by any stretch. Backing up the entire file when it changes does not qualify as differential.
:-(
What I want to know is if Apple fixed the glaring hole where files that are (relatively) short lived disappear when a particular backup is 'promoted' for (eg) hourly to daily. If a file that was created after the last daily backup but deleted before this one is promoted, you're SOL.
Some backup...
I suspect this is not fixed, but I don't know. Anyone?
Uh, you're missing the point... The GP was saying that he thought the 'emotional' issues (flag-burning, gay marriage, etc.) were less important to base your voting on than the important ones: health care, economy, Iraq, and the environment; things that a federal government needs to do something about.
Read it again. Intel has patched the bug, that's why he's talking about the Intel bug. Apple has not patched anything, let alone acknowledged the bug.
This is what I did. I taught 2 semesters of Java (intro and 'advanced'). during the 'intro' semester I did not use any IDE. I wanted to be sure that the students understood the basics of how to develop: edit, compile test, rinse, repeat. IDEs are not conducive to this. Too many mistakes that are excellent learning opportunities are missed in an IDE. Understanding that class/variable naming makes a difference for the understanding of your program, and that you need to think about what you call your idetifiers; Actually running the compiler to generate (in this case) the byte code that will be run. An IDE glosses that over for you. There are many more things that make the non-IDE method good for the intro-type classes.
When I taught the same people the 'advanced' class, I started them out with an IDE. Just the fact that they realized how many things the IDE did for them was a major learning experience. Catching syntax errors, color coding, compiling, documentation links, etc. IDEs do, however, nudge you towards a particular way of programming, which may not be desirable. Syntax errors are caught immediately, which when you're writing a new piece of code with new variables, etc. becomes a distraction. You feel like you have to fix the syntax error before you can continue with your new code. Especially when you're just learning, this will make you lose your train of thought, and can get annoying pretty fast.
Anyway, bottom line: I am in favor of using the non-IDE approach for getting started with programming, and then graduating to an IDE. Not because "I had it bad, so you have to as well", but I really think there's merit in learning the basics of it, to gain a more complete understanding of the process of development.
Just yesterday, I went to http://www.intuitmarket.com/ with Firefox, and got booted for not using
Wouldn't even let me in with FF...
Yeah, they do need the phone line. Not to get the guide, but to make PPV purchases. If you don't do that (PPV), you might be OK without a POTS line, except for during setup.
I'm glad to hear that you are capable of sending more than 5 messages/hour. ;-)
WRT the lists, etc. I was actually thinking of counting the incoming connections to the MTA (ie. you connecting to sendmail), not the outgoing (sendmail connecting to the world). Of course this is not fool proof, and perhaps 5 is not the right number, and maybe an hour is not the right time unit. Maybe it should be more like 'if you send more than 5 messages/hr for a period of 12 hours from your PC, you will be blocked'.
Hmmm... Does anyone have more details on that number? Where did you see this?
I'd really like some hard data so the problem can be prioritized. All I've seen in this discussion so far, is "Most" or "almost all", or (as above) "80+%". No sources for this info, or explanation about it.
Sigh!
BTW, I'm not being an apologist for botnets or anything, but I'd really like to know how big this problem is, and I can't seem to get any actual dta on this. Someone must have done some crunching of logs, to get some idea of the extent of the problem...
RTFA! While Carl seems to rip on most established techniques for stopping spam, that's only because they don't work very well. If they did, why would huge masses of people still be complaining about loads of spam in their inboxes? He also does say that many of the techniques should still be used, but that they won't solve the problem. Quoth: They are a band-aid...
Really?
How do you know this? I'd love to see the stats that support this. I'm not trying to be facetious, I'd really like to get hard data like that.
I agree 100% with Carl. Forcing admins to get a clue about the state of their outbound mail is key. And as he says, there are ways to control all this stuff. Even trojaned PCs can be controlled, by limiting the number of outbound messages from that machine to something reasonably low (like 5/hour). If the machine goes over that, you have (most likely) found a trojaned machine.
Of course, there are going to be significant costs to this approach in the beginning, because of the (presumably) large number of pwned PCs in the world. However, the ongoing cost of keeping up with spam complaints, storage requirements, and bandwidth costs should exceed the price of handling a large load of complaints over a relatively short term (giving a quick ROI), which all PHBs (including myself) like to use to sell it to higher-ups.
It's a matter of political will to get something like that through. That's why it won't work in the US, as long as we have oil-men running the country.
But the point is that they were testing "less mature" OSS against something commercial.
To me, the upshot is that even stuff that's still in development is about as "bug-free" as commercially available wares. A win for OSS in my book!