It's a scam. If they really intended to give you the discount, they'd have an "instant rebate", meaning a price-cut in the store.
People always say this, but I'm not convinced. I've sent in and received a whole bunch of rebates over time, and I don't immediately recall sending one in and never getting it back. I'm also very careful to follow the instructions to the letter.
However, it still is better for them because people forget about or don't bother with the rebates. When I got my monitor, it was $300 with a $50 rebate. However, I didn't send in the rebate immediately, it got buried and forgotten about until I unearthed it a few months later, and they kept their $50.
I think this is probably the biggest reason that they offer rebates instead of in-store discounts. I also wouldn't be surprised that they have people looking out for any procedural issues that would give them an excuse to deny the rebates, but I've never heard any evidence that there's an active conspiracy to defraud or anything.
(Rebates also means that, if you cut the UPC out, you are probably going to have a hard time returning it to the store.)
Quitting is by far the easiest way to ensure that cookies and current login sessions and whatnot are wiped.
You want to set it up so that when your browser is exited, it is automatically restarted. U Wisconsin has public kiosks around campus that work this way.
(I don't think you want to make them log in and out and such. Just make it so you walk up, and the browser is there running.)
Or did someone issue an edict that Linux kernel code can't be dual-licensed, at some point when I wasn't paying attention?
I think the point of the story is the following: 1. Developer A writes some code for OpenBSD (or whatever) 2. Developer B says "that's cool, I wish Linux had that" 3. Developer B ports developer A's code to Linux 4. Developer B then starts improving on A's code
However, developer B doesn't want to release his changes under the BSD license, so the improved version goes out GPL-only. Developer A says "hey, wait, that sucks", because now he can't incorporate those changes back into OpenBSD, which does (I assume) have a policy that all code must be BSD-licensed.
One one hand, it's unfortunate, because OpenBSD loses out. On the other hand, the original author wrote the code knowing that someone could take it and not release changes (for instance, incorporate it into Windows or Mac OS X or SunOS or something like that), and this really isn't all that much different.
Oh, and NTP is absolutely vital when doing any synchronisation.
You could also keep version numbers around. Increment the version number on change. When syncing, look at the original version number and whether it has been updated. That's all you need to know to determine if there's been a conflict.
If you want to get really fancy, you could store a hash of the original version. That protects against "changes" that are really just changes to the same thing.
If you want to suggest Unison, provide a description of how to work around the problems that are mentioned in the question you're trying to answer. He even linked to the same site you link to!
(And yes, there are some, but mentioning Unison doesn't help. The poster knows about it already.)
You can merge the changes together in some reasonable way as long as the files are edited in local spots.
Usually. The spots have to be independent too; not checking CVS or SVN merges before committing (even if they don't conflict from CVS's point of view) is a great way to sometimes break the build.
The information on how to use this hack is not publicly available.
Um... what?
You mean besides this diagram of the steps you should follow when making a backup (and a similar one for restore), and the MSDN documentation for the VSS.
My current thinking is that I'd need to set up a server on my laptop, and then have the client talk to the local server.
I haven't actually used Coda, though I'm planning on it for a small network myself, because this is exactly what it was designed to do. But why would you need the server on the laptop? All you should need is a client. Have you tried it that way and it didn't work or something?
...remember what happened last time Microsoft tried to do one of those?...they produced a set of patches that are widely regarded as being noticeable improvements to their OS, and which mark the point where several places decided that XP became usable?
I'm not sure that's enough. There also needs to be a convention in place that means, for instance, that a particular application only reads and writes keys within a certain, easily determinable key range (otherwise what keys to I move over when I want to migrate?), or possibly a couple ranges (like application settings and WM settings or something).
I think I also want to see separate files for each application that correspond to those ranges, instead of a single, monolithic one. This isn't essential (you can back up certain keys in the Windows registry), but I still think I would like it. (Alternately: make a view of the registry as a file system, a kind of ConfFS, that is mounted at ~/.conf,/etc/conf, etc. Actually, now that I've thought of this, I really like it.)
After all, your description above is, at some level, the same as how programs should treat the registry: HKLM is your/etc/conf/conf.conf, and HKCU is ~/.conf/conf.conf. (There isn't really an equivalent to the groups configuration, but that seems more complicated: you need to define an ordering on the groups.) The only difference is that the inheritance should be automatic (and is in your description), while in Windows it has to be written in. (I.e. I think a program would need to explicitly check in one place, then the other to get the settings that way.) Even this isn't true in the case of HKCR, which is built almost exactly as you describe. (It's a union of the appropriate sections from HKCU and HKLM, giving preference to HKCU.)
Yes, but that's a different question in some sense.
Why do we have Gnome and KDE? (Actually I should say GTK and Qt...) They both do about the same thing, they both run and don't run on about the same systems. My understanding is that we have both originally because of licensing issues, but we have both now because they think that the systems should go in different directions, and also because of developer egos.
But as a user, I don't care about that. What I see is that Gaim doesn't fit in with the rest of my KDE apps, because it uses GTK widgets instead of Qt.
This is the sort of inconsistency that I'm talking about, not that you need systems tuned differently for different applications.
Tracing through a series of macros (some with all-lowercase names, in violation of the standard C convention of the last thirty years)...
I once spent 20 minutes swearing at GCC for giving me a nonsensical error message that I ultimately found out was caused by me using "current" as a local variable name, which conflicted with the "current" CPP macro.
Every now and again there's a macro that (arguably) shouldn't be all caps, but "current"? Give me a break. I was tempted to submit a patch renaming it to CURRENT_I_HATE_YOU_ALL everywhere it's used, but of course never did it.
Second, build infrastructure that's obviously missing. There needs to be a central "registry". Let me rephrase that; a central key-value pair repository. Make it and let everybody know. Make sure drivers (X Server / Kernel) can talk to it and applications can talk to it and read/write
I've thought about this for some time, and I'm still on the fence as to whether it's a good idea. I definitely think that the Windows way is wrong. I'm not convinced that a registry-like thing is a bad idea, but you have to do it carefully.
Besides the obvious issues like stability, reliability, security, scalability, and performance, I have what I consider a critical feature: is it easy to figure out what settings a particular program uses and delete, backup, or move them to a new computer?
I can't do that with the Windows registry, not by a longshot. I can do that with Unix dot-files.
A "centralized" registry doesn't preclude being able to do this, but if you can't, then I think it shouldn't be done.
Slashdot Mirror
Check "automatically accept next HIT" or whatever it is, enter anti-bot CATCHPA, then it works sort of as you want.
It still could be a lot better, but it's not horrible once you see that checkbox.
Someone's firing too much magic missile.
It's a scam. If they really intended to give you the discount, they'd have an "instant rebate", meaning a price-cut in the store.
People always say this, but I'm not convinced. I've sent in and received a whole bunch of rebates over time, and I don't immediately recall sending one in and never getting it back. I'm also very careful to follow the instructions to the letter.
However, it still is better for them because people forget about or don't bother with the rebates. When I got my monitor, it was $300 with a $50 rebate. However, I didn't send in the rebate immediately, it got buried and forgotten about until I unearthed it a few months later, and they kept their $50.
I think this is probably the biggest reason that they offer rebates instead of in-store discounts. I also wouldn't be surprised that they have people looking out for any procedural issues that would give them an excuse to deny the rebates, but I've never heard any evidence that there's an active conspiracy to defraud or anything.
(Rebates also means that, if you cut the UPC out, you are probably going to have a hard time returning it to the store.)
Maybe what we need is to actually start trying to hold companies to account.
I've been documenting whenever I send one in (photocopies of all the forms and such), I should start paying attention to whether I get them back.
Damn, I just used up my last mod point earlier today.
- Disable quit
NO! Don't do this!
Quitting is by far the easiest way to ensure that cookies and current login sessions and whatnot are wiped.
You want to set it up so that when your browser is exited, it is automatically restarted. U Wisconsin has public kiosks around campus that work this way.
(I don't think you want to make them log in and out and such. Just make it so you walk up, and the browser is there running.)
Or did someone issue an edict that Linux kernel code can't be dual-licensed, at some point when I wasn't paying attention?
I think the point of the story is the following:
1. Developer A writes some code for OpenBSD (or whatever)
2. Developer B says "that's cool, I wish Linux had that"
3. Developer B ports developer A's code to Linux
4. Developer B then starts improving on A's code
However, developer B doesn't want to release his changes under the BSD license, so the improved version goes out GPL-only. Developer A says "hey, wait, that sucks", because now he can't incorporate those changes back into OpenBSD, which does (I assume) have a policy that all code must be BSD-licensed.
One one hand, it's unfortunate, because OpenBSD loses out. On the other hand, the original author wrote the code knowing that someone could take it and not release changes (for instance, incorporate it into Windows or Mac OS X or SunOS or something like that), and this really isn't all that much different.
Why would anyone trust code on people who cannot even keep on to their own?
Trust them to do what?
award patents with the magic 8 ball procedure (pat. pend.)
Clearly they aren't using a magic 8 ball. The magic 8 ball sometimes says no.
Oh, and NTP is absolutely vital when doing any synchronisation.
You could also keep version numbers around. Increment the version number on change. When syncing, look at the original version number and whether it has been updated. That's all you need to know to determine if there's been a conflict.
If you want to get really fancy, you could store a hash of the original version. That protects against "changes" that are really just changes to the same thing.
Read the summary! Unison alone won't do it.
If you want to suggest Unison, provide a description of how to work around the problems that are mentioned in the question you're trying to answer. He even linked to the same site you link to!
(And yes, there are some, but mentioning Unison doesn't help. The poster knows about it already.)
You can merge the changes together in some reasonable way as long as the files are edited in local spots.
Usually. The spots have to be independent too; not checking CVS or SVN merges before committing (even if they don't conflict from CVS's point of view) is a great way to sometimes break the build.
Why does this post get modded redundant but the 47 suggesting rsync and/or Unison don't?
The information on how to use this hack is not publicly available.
Um... what?
You mean besides this diagram of the steps you should follow when making a backup (and a similar one for restore), and the MSDN documentation for the VSS.
My current thinking is that I'd need to set up a server on my laptop, and then have the client talk to the local server.
I haven't actually used Coda, though I'm planning on it for a small network myself, because this is exactly what it was designed to do. But why would you need the server on the laptop? All you should need is a client. Have you tried it that way and it didn't work or something?
I do hear it's a pain to set up though.
...remember what happened last time Microsoft tried to do one of those? ...they produced a set of patches that are widely regarded as being noticeable improvements to their OS, and which mark the point where several places decided that XP became usable?
It's not a truck either. You can't just dump stuff on it.
Ah, interesting. I didn't know that. Thanks for the info.
Battery? Surely they're running on electricity generated by the engines.
Not that power considerations are unimportant because of that, but they aren't that critical.
Every day? I'd do it after every flight. They have enough other things going on then.
Or use something like Knoppix, where things aren't written to stable storage at all. (Surely there would be a way to make RedHat behave that way.)
I'm not sure that's enough. There also needs to be a convention in place that means, for instance, that a particular application only reads and writes keys within a certain, easily determinable key range (otherwise what keys to I move over when I want to migrate?), or possibly a couple ranges (like application settings and WM settings or something).
/etc/conf, etc. Actually, now that I've thought of this, I really like it.)
/etc/conf/conf.conf, and HKCU is ~/.conf/conf.conf. (There isn't really an equivalent to the groups configuration, but that seems more complicated: you need to define an ordering on the groups.) The only difference is that the inheritance should be automatic (and is in your description), while in Windows it has to be written in. (I.e. I think a program would need to explicitly check in one place, then the other to get the settings that way.) Even this isn't true in the case of HKCR, which is built almost exactly as you describe. (It's a union of the appropriate sections from HKCU and HKLM, giving preference to HKCU.)
I think I also want to see separate files for each application that correspond to those ranges, instead of a single, monolithic one. This isn't essential (you can back up certain keys in the Windows registry), but I still think I would like it. (Alternately: make a view of the registry as a file system, a kind of ConfFS, that is mounted at ~/.conf,
After all, your description above is, at some level, the same as how programs should treat the registry: HKLM is your
Yes, but that's a different question in some sense.
Why do we have Gnome and KDE? (Actually I should say GTK and Qt...) They both do about the same thing, they both run and don't run on about the same systems. My understanding is that we have both originally because of licensing issues, but we have both now because they think that the systems should go in different directions, and also because of developer egos.
But as a user, I don't care about that. What I see is that Gaim doesn't fit in with the rest of my KDE apps, because it uses GTK widgets instead of Qt.
This is the sort of inconsistency that I'm talking about, not that you need systems tuned differently for different applications.
Tracing through a series of macros (some with all-lowercase names, in violation of the standard C convention of the last thirty years)...
I once spent 20 minutes swearing at GCC for giving me a nonsensical error message that I ultimately found out was caused by me using "current" as a local variable name, which conflicted with the "current" CPP macro.
Every now and again there's a macro that (arguably) shouldn't be all caps, but "current"? Give me a break. I was tempted to submit a patch renaming it to CURRENT_I_HATE_YOU_ALL everywhere it's used, but of course never did it.
Second, build infrastructure that's obviously missing. There needs to be a central "registry". Let me rephrase that; a central key-value pair repository. Make it and let everybody know. Make sure drivers (X Server / Kernel) can talk to it and applications can talk to it and read/write
I've thought about this for some time, and I'm still on the fence as to whether it's a good idea. I definitely think that the Windows way is wrong. I'm not convinced that a registry-like thing is a bad idea, but you have to do it carefully.
Besides the obvious issues like stability, reliability, security, scalability, and performance, I have what I consider a critical feature: is it easy to figure out what settings a particular program uses and delete, backup, or move them to a new computer?
I can't do that with the Windows registry, not by a longshot. I can do that with Unix dot-files.
A "centralized" registry doesn't preclude being able to do this, but if you can't, then I think it shouldn't be done.
Herding cats becomes a lot easier if you have catnip. ;-)