I didn't say never look at them, I said never remove the extra photos from your Lightroom catalog, find the files on disk, delete them, and hope you didn't accidentally delete IMG_8192.JPG instead of IMG_8191.JPG. And yes, it *is* easier to just store them than to do that. If hard drive sizes stop increasing, or the photo cataloging software gets better, that may change. In the mean time, the disk space is cheaper and easier than the time to deal with it.
It really depends on why you're taking the pictures. If you are just trying to have the memory, then yeah, you don't need 15 pictures in sports mode. But if you're trying to do something artistic then that's how you do it. And while you *can* sift through and delete all the ones that aren't the best, it's a lot easier to *not* have to do that and just store 'em. How much is your time worth vs. $250 for an 8 TB hard drive that can store, probably, all the pictures we'll take in the next 15 years.
Yeah, but a better camera will be more than that. My wife and I took over 7000 pictures on our honeymoon (which lasted about a month) with a Canon camera. That's about 7MB/picture (seems to go up to about 12 for JPEG). If we'd taken them in RAW (which, arguably, we should have since some of the shots would be nice to reedit or do lens correction on) it would've been around 25 to 30MB/image with our camera. If you use sports mode (taking 10 or 15 shots every time you push the button), I could easily see hitting 100GB/month. All depends on whether this guy's wife is as obsessive about her "recreation" as my wife and I are....
I design audio for theater. I have a 3TB archive of my designs and it grows about 300GB per year (musicals, where I do recording, take about 100GB per show). My wife likes taking pictures and she generates a few gigabytes per month of pictures. Many people keep movies. My parents have an archive of their favorite (broadcast) TV shows that they recorded with EyeTV. You're right that it's extremely likely that nobody will care about most of this stuff when we die. But we're still alive. What's so hard to understand about that?
Yeah, I could spend hours paring down my audio collection. I could delete the musical recordings, eliminate duplicates, and throw away shows I'm likely to never revisit. My wife could delete most of her pictures (ones that were out of focus, test shots, ones that she doesn't like for some reason). My parents could buy DVDs (which are simply a less convenient form of storage). But why would any of us do this? I occasionally get asked to remix songs and I reuse sound effects from shows sometimes. My wife goes back and looks at shots or may change her mind about what she wants to keep.
When you can fit 8TB on something the size of a medium book, why wouldn't you keep stuff you might use again?
THIS (* see below) dizzying pile of config files with nondescript names. And that doesn't even include the set of names that are magically generated either implicitly and from other files. For reference,
To answer a non-rehetorical question: Can any of the systemd lovers (or haters, I'm not picky) tell me how the heck I move
(*) The list was going to go here. But it's so long Slashdot won't let me post it. There are 255 unit files in
Yeah, I was surprised as well. It's normal to relay in the US as well. I switched to Comcast earlier this year from CenturyLink. With CenturyLink, I was relaying through their SMTP server. Comcast doesn't allow that (at least on Business Class accounts).
You can't use that on a Comcast Business account (or at least my Comcast Business account couldn't). After 4 phone calls, they finally confirmed that their mail server won't send mail for anyone else's domain. Ie, if you own example.com, Comcast's server won't relay mail for firstname.lastname@example.org only for email@example.com.
Now.... My information is about 7 months old so maybe they changed this without telling anyone? If your information is newer I should probably revisit my mail configuration.
Meantime, I just tried from my domain (email server sends directly from a Comcast Business IP) and had no problems sending to Yahoo Mail so they aren't blocking *ALL* Comcast Business IP's. I also have (hopefully) correct reverse DNS on my email server and SPF records in my DNS.
(Now if Stripe is applying their rules differently for different people, that *is* a problem. If, for instance, they'd happily process payments for a gun store/manufacturer owned by a Democrat but not a Libertarian or a Republican, *that* I'd have a problem with even though I tend to be a Democrat).
There is actually a huge difference in the argument you are making. There's a difference between choosing *who* you do business with (or employ) and *what kind* of business you are willing to be in. If you're a gun store and you refuse to sell someone a gun because they're gay, that should be illegal (whether it actually *is* illegal is still being debated). If you're, say, a department store and you don't wish to be in the business of selling guns, you should have a right not to be. I think this case is pretty clear cut that the payment processor has a right not to be in the business of processing payments for guns.
The incident you are thinking of is, I think, when Neil Armstrong crashed in the Lunar Module Simulator.
Apparently the story goes that he was back in his office eating lunch a few hours later like nothing happened.
The RSO's are actually not even from NASA. They are from the US Air Force 45th Space Wing (I knew that was true at KSC and Wikipedia confirms it's the same group that does Wallops).
...except that I'm talking about *corrupt* logs, not *correct* logs. I maintain that in the face of corruption, a human parsing an ASCII log will beat a computer parsing a non-ASCII log any day.
NO! I don't see why this is so hard to get. ASCII is a one to one mapping with human language. "Binary" logs (i.e., logs with an encoding other than 7 bit ASCII since we're going to be SUPER pedantic here apparently) are not. Especially if they are compressed or the encoding is complicated in other ways. When stuff gets corrupted the best filter for that corruption is the human brain. But that assumes the brain can parse the encoding. I can parse the English alphabet (and the Spanish one on a good day).
What do you think will happen if I want journald to parse, say, "ap#@1e2: p@#$ission denied"? Is that going to correctly end up with "apache2: permission denied"? I doubt it. But I probably will. Especially if I already know that I'm having issues with Apache. And if you don't like that example, I'm sure I can come up with a lot more.
The implication isn't that SysV init is problem free. The implication is that SysV init is *debuggable*. A 900+ edge directed graph that controls my system startup is *not* debuggable. Especially when some of the nodes and edges are created implicitly (if you're wondering what I'm talking about, ask systemd to produce a dot formatted graph of the startup process. Just don't ask it to do that in a chroot environment because it won't, but that's a different rant). Oh - and it seems to ignore some of the dependencies (edges in the graph) but not others.
Because 85% (a number I just made up) of the point of log files is to *figure stuff out when things go wrong*. When things go wrong, binary logs sometimes end up corrupted (witness all of my journald logs from last week - no, I don't know why yet). I am a *LOT* better at sifting through a corrupt text log than a computer is at sifting through a corrupt binary log. Journald just says "your log is corrupt" and I lose. I've noticed that even "strings" doesn't get text out of a (non-corrupt) journald log (at least not all the logs, maybe some of them?). Now please give me *one* advantage of binary logs over properly formatted text logs. The reason syslog is so hard to parse is that it splits lines stupidly. There's no (modern) reason for that. So when I say "properly formatted", I definitely don't mean syslog as is. Think syslog with lines of any length.