File extensions are useful for automation, of sorts. For example, I keep stock photos with.sjpg and.spng extensions, set to open in my image editor, while.jpg and.png open in my image viewer. They're JPEG and PNG images in either case; it's the extension that makes that automation possible.
But the defaults are mutable, and not to be trusted to stay consistent.
Your point? The defaults would still be mutable even if we used magic numbers, or some other system, instead of extensions.
There is nothing that prevents an application from changing the default for.gif from opening in [gif viewer of choice] to executing them. If someone then sends you an executable with a.gif extension, and you double-click it, it will execute the executable.
You have a point. However, there is nothing that prevents an executable from using an icon that looks like an image thumbnail (after all, that's all an icon really is). Trusting that an icon properly identifies a file is folly.
Unix(-like) systems have this pretty well handled on the command line, since you can see right there, in the directory listing, whether the executable bit is set. If a GUI is more your speed, what is actually needed is for the GUI to apply some type of overlay to the icon displayed for each file, to indicate what it will attempt to do when that file is opened. That only works if you're displaying icons and, then, if the icons are big enough to be useful (in list views, they usually aren't), though, so some color-coding of file names should be done, as well.
Or, common sense, look at the file header before opening it if you don't trust the source; and you should *never* trust the source.
That.jpg might not actually be an image, but Windows will try to load it like one.
As will OSX. In fact, on both platforms it is possible to exploit that behavior to your own benefit as a user. Try configuring your OS to open.jpg in a viewer and.jpeg in an editor. Now, name all of your working copies.jpeg and all of your finals.jpg and enjoy having all of your working copies automatically open in your editor, while all of your completed work defaults to the viewer.
Only possible when the OS makes intelligent use of file extensions; the people we're arguing with don't seem to comprehend the usefulness of this, though.
Well, that was uneventful. The results are so close to the other test there's no point posting them. I'm also too damn lazy to install Mavericks or Mountain Lion on a spare SSD to test there, but I know for certain that the issue I mentioned previously did actually occur the last time I tried it (which was *not* on my current platform, Yosemite). Either way, looks like Apple has fixed that performance killer now, so it's a moot point.
On the SATA SSD, the results for the flat 100k files were:
CLI: 3.038s
Finder: 4.82s
Surprisingly, Finder did better on the slower disk.
The 4-levels-nested test results were:
CLI: 2.904s
Finder: 4.83s
Another interesting result, the slower SATA-based SSD was actually faster than the PCIe-based SSD, in both tests. It's also possible that Apple optimized the algorithm Finder uses to build its file list in Yosemite; I'm pretty sure the last time I tried to delete a large batch of files via Finder was under Mavericks, possibly Mountain Lion.
Now, here's the kicker: I didn't actually run this test on the old MBP. The SSD that used to be in that system is currently connected to this system via USB3. That makes these results even more interesting, wouldn't you say?
Methinks disk cache has something to do with that, so I'm going to do one more set of tests, ejecting and remounting the disk in between the writes and the deletes, to ensure that the none of the deletes are acting against writes that haven't yet been committed to disk.
Well, that was an interesting result for sure... I just had Finder freeze up on me, using 99% CPU, while I was *creating* the 100k files *on the command line*. I could understand that if I had the folder open in Finder while creating the files, but I didn't.
So, the CLI delete took 3.12 seconds, while deleting via Finder took 5.92. A much faster result than I'm used to, but then, it was a single level deep; though Finder did take nearly twice as long. Time to test multiple levels of nesting, like I mentioned previously. Also, I did know about CMD-Delete. That's how files get moved to the trash on my system. It's been that long since I've deleted files via Finder; I actually forgot how for a moment. Shift-CMD-Delete gives me an error chime and does nothing. What hidden configuration or 3rd-party utility are you using to enable the key combinations you mentioned?
For reference, here's the bash script I used to create the files:
#!/bin/bash
mkdir bigdir
for i in `seq 1 100000`;
do
echo '' > bigdir/$i
done
Didn't know about CMD-Delete or Shit-CMD-Delete, actually. Never needed to know, I've been deleting things from the CLI for much longer than I've been using a Mac. I also haven't tried deleting 10k+ files in Finder in the couple of months I've had a Retina MBP; my previous MBP had a SATA SSD that could max out the bus, though, and started bogging down around 10k and would crap out around 50k. That was a quad core with 16GB of RAM (where Apple would only support configurations up to 8GB, so I imagine the problem would be worse for users who limit themselves to what Apple sells).
In fact... hell, let me put your claims to the test.
Not entirely true. Let's say you have a PNG file, image.png, with the executable bit set. Doublie-clicking it in Finder will open it in your image viewer. Renaming it to image.png.app or image.app, then trying to open it, will cause OSX attempt to execute it, then complain that it is not supported. Removing the extension, then trying to open it, will cause OSX to attempt to execute it in a shell if the executable bit is set, or scan for a recognizeable header to determine file type and open the correct application, if the executable bit is not set. In only one of those cases is the extension optional, and even then, it's useful; for example, you can set.jpg to open in a viewer and.jpeg to open in an editor, so you can easily identify working copies and have them automagically open in your editor; the same works for pretty much any file type, provided that either your viewer or editor can be configured to recognize and handle alternate extensions.
You also never actually know whether that image (or at least, the file you *think* is an image) is actually an image. Using the file extension hints to you that it is an image and tells the system to treat it as one, so you don't end up with a file that looks like an image, but actually formats your hard drive. If your file has the wrong extension, you change it in Finder or on the command line, just as you would change it in Explorer or on the command line in Windows. As an added bonus, there is no executable file extension; it's a permission that gets set, and the file extension still takes precedence. That is, if you set notanimage.jpg to be executable, then try an open it in Finder, it'll open it in your image viewer, ignoring the execute bit entirely; only when you remove the extension does it actually attempt to execute.
The way OSX does it is correct, IMO. And 4 years ago I never thought I'd be saying that.
We were of the same mind right up until your last sentence. Finder is good for browsing, shit-slow for copying or deleting more than a handful of files, and doesn't actually delete, which adds an extra step (emptying the trash). Because of this, I find that Finder is better utilized for browsing, especially media collections, while the command line is often faster for manipulation. Try deleting a folder with several subfolders, several levels deep, and over 10k files; make a copy first, so you can do it in Finder, then again on the command line. Time them. In fact, make two copies, one from Finder and one from the CLI, and time those, too.
Of course, if you're routinely deleting one or two files at a time, or just a handful here and there, then the difference is immeasurable, if there even is one; but if you have to do any sort of bulk deletes, Finder will choke on the file list[1]. Of course, you still have to manually empty the trash before the file actually gets deleted; this more than doubles the time an actual delete operation requires; one pass to move files to the trash, another pass to actually delete. It's even worse on network volumes, since those are much higher latency, and often much slower, to begin with.
[1] - Admittedly, so well rm, but it takes a lot more files and will at least tell you about the condition and exit gracefully, so you can break the operation into smaller chunks or use find's -exec option instead, whereas Finder will just sit there, frozen, and prevent you from ejecting the disk or even rebooting gracefully
I may do so at some point in the future, since there seems to be some interest in it. I would want to run anything like that by an attorney first, since I'm fairly certain it does constitute legal advice.
And if I don't want to use a GUI? Seems your steps should still be applicable to the CLI. That being said, you're rewriting history when doing that, and that is considered a huge no-no when using Git, especially when you have a team of developers. You'll have a local branch without the commit you just skipped over, but everyone else will still have that commit in their history, meaning they'll all still have the "bad" code. It's probably fine if you're the sole developer, but it's generally not advised to assume that will always be the case. Methinks I'll not follow your advise on this.
And my comment was about clients making changes to the spec. It doesn't matter how good your estimate is or how perfect your project plan is if the client decides to change the project after work has begun. You can refuse the changes, but they can also refuse to pay. You can give up the job, but hey, you're still not getting paid if you do that. The best hope you have is for the client to understand that their change, no matter how trivial it may seem, means more work for you and, therefore, more cost for them.
Or, to put it another way, go ahead and estimate the cost of that paint job. Then build a project plan for it that holds up in the situation I described. I'll be pricing you against a few local shops who are known for quality work; you high has to be competitive or I'll go elsewhere.
This isn't as much of an issue when your client is internal to the company, but that was clearly not the case in my analogy.
And yet, you still get know-nothings who insist that you're wrong and want to push forward anyway. Thankfully, for the ones I've encountered, money is not an object and they're more than happy to pay for the work to be redone. I had one client try and argue the point and I told them very plainly that their options were to continue the project as originally detailed, take the incomplete work, as-is, or pay for the changes they were requesting. Which option they took is irrelevant, but I'll say the project got done and I got paid.
That doesn't negate the fact that people will still insist on changes, no matter how careful you are in communicating issues you find in their requirements and getting clarification before starting work. You're absolutely right, though; many people don't know how to handle it when it happens.
My example was meant to highlight the fact that a single word change in the spec can mean having to redo work. No matter how easy it is to *undo* the work (in the case of programming, it's often much easier than in my analogy, but this is not always the case), the fact remains that the work must still be redone. Just because my analogy did not include having done work that needs to be kept, subsequent to having done work that needs to be redone, doesn't make my honest curiosity irrelevant; and your response seems to indicate that, save for having planned for that very occurance, it is indeed not possible (and even with planning, only maybe, if you're willing to create a new branch for nearly every commit... and you're lucky).
Honestly, I was hoping you'd tell me it was easy. This is one of those instances where I'd jump for joy while screaming at the top of my lungs "I WAS WRONG! I WAS WRONG! THANK YOU, LORD, I WAS WRONG!" Not that I have a use for it at the moment, but it's come up in the past and I'm sure it'll come up again in the future.
You still end up rewriting code. Version control is great for many things, including rolling back to a previous point in time, but please tell me how to undo something I did last week without rolling back everything I've done since. I'd actually really like an answer to that, with regards to Git, if you've got one.
You've got a few years on me, actually! I've just spent a little over 4 years working for a guy who's made some real boner mistakes and got to learn form him.:)
I'll drop you an email in the AM, I really should be asleep right now.
I have a project that was due last week that I haven't started on yet. I got the deposit check the day I handed over the SoW, but didn't get the signed SoW back until last week, 6 weeks later. As per the terms of the SoW, I'll reschedule it when I find time.
Most of the delays I encounter are caused by someone else; either the need to refactor someone else's shit code (that I wasn't allowed to review before providing an estimate, of course), delayed approval for the work, delayed access to resources, any number of external forces. Very rarely do I exceed my estimated *hours* for a project unless changes are requested (but then I'm not exceeding the estimate, either, since I make the client either agree to a new estimate or accept a refund of any portion of their deposit not already applied to the hours I've worked), but all too often I find myself completing projects well past their due date because some resource wasn't made available to me until after that date had lapsed.
Fortunately, I foresaw that unforeseen things would happen when drafting the boilerplate language of my SoW and covered all of those cases. I go over the entire SoW with my clients before starting a project and make sure they know what the triggers are for a re-quote, what will cause the project to be delayed, and under what circumstances they're entitled to a refund of any deposit they pay (e.g. if they back out of the project once I've started work, I'm deducting my hours from that). As a result of that, and perhaps a bit of luck, I haven't had any disputes over project scope, budget, or timeline, and the one client I did have back out of a project simply said they no longer had the budget (they were being sued) and told me to hold on to the remainder of their deposit as they'd be back to finish the project after they lawsuit ended, hinting that, even if that didn't happen, the small sum would make no difference going forward (of course, I'm sitting on that money for now, and if they fully back out of the project I'll insist that they either accept the refund or sign a document releasing the funds to me).
That was one thing that really pissed me off when I was working for someone else; I had no control over external interruptions or delays and it was usually the person interrupting and delaying me who was holding me accountable for all of them. I'm not out to scam anyone, but I always felt like I was when dealing with my previous employer.
He may have been able to write more maintainable, more stable, better tested, and altogether cleaner code, given what he asked. Possibly in half of his worst-case estimate of 2 years. In the long run, the crap that needed to be slapped together to get the project "done", in 4x the time he was allotted, will end up costing the company more than giving him what he asked for in order to do it right. You must be an MBA.
Slashdot Mirror
File extensions are useful for automation, of sorts. For example, I keep stock photos with .sjpg and .spng extensions, set to open in my image editor, while .jpg and .png open in my image viewer. They're JPEG and PNG images in either case; it's the extension that makes that automation possible.
But the defaults are mutable, and not to be trusted to stay consistent.
Your point? The defaults would still be mutable even if we used magic numbers, or some other system, instead of extensions.
There is nothing that prevents an application from changing the default for .gif from opening in [gif viewer of choice] to executing them. If someone then sends you an executable with a .gif extension, and you double-click it, it will execute the executable.
You have a point. However, there is nothing that prevents an executable from using an icon that looks like an image thumbnail (after all, that's all an icon really is). Trusting that an icon properly identifies a file is folly.
Unix(-like) systems have this pretty well handled on the command line, since you can see right there, in the directory listing, whether the executable bit is set. If a GUI is more your speed, what is actually needed is for the GUI to apply some type of overlay to the icon displayed for each file, to indicate what it will attempt to do when that file is opened. That only works if you're displaying icons and, then, if the icons are big enough to be useful (in list views, they usually aren't), though, so some color-coding of file names should be done, as well.
Or, common sense, look at the file header before opening it if you don't trust the source; and you should *never* trust the source.
That .jpg might not actually be an image, but Windows will try to load it like one.
As will OSX. In fact, on both platforms it is possible to exploit that behavior to your own benefit as a user. Try configuring your OS to open .jpg in a viewer and .jpeg in an editor. Now, name all of your working copies .jpeg and all of your finals .jpg and enjoy having all of your working copies automatically open in your editor, while all of your completed work defaults to the viewer.
Only possible when the OS makes intelligent use of file extensions; the people we're arguing with don't seem to comprehend the usefulness of this, though.
Huh, they run just fine on mine. Must be all the Wine.
Well, that was uneventful. The results are so close to the other test there's no point posting them. I'm also too damn lazy to install Mavericks or Mountain Lion on a spare SSD to test there, but I know for certain that the issue I mentioned previously did actually occur the last time I tried it (which was *not* on my current platform, Yosemite). Either way, looks like Apple has fixed that performance killer now, so it's a moot point.
Thanks for prompting this bit of testing.
On the SATA SSD, the results for the flat 100k files were:
CLI: 3.038s
Finder: 4.82s
Surprisingly, Finder did better on the slower disk.
The 4-levels-nested test results were:
CLI: 2.904s
Finder: 4.83s
Another interesting result, the slower SATA-based SSD was actually faster than the PCIe-based SSD, in both tests. It's also possible that Apple optimized the algorithm Finder uses to build its file list in Yosemite; I'm pretty sure the last time I tried to delete a large batch of files via Finder was under Mavericks, possibly Mountain Lion.
Now, here's the kicker: I didn't actually run this test on the old MBP. The SSD that used to be in that system is currently connected to this system via USB3. That makes these results even more interesting, wouldn't you say?
Methinks disk cache has something to do with that, so I'm going to do one more set of tests, ejecting and remounting the disk in between the writes and the deletes, to ensure that the none of the deletes are acting against writes that haven't yet been committed to disk.
Nested 4 levels deep, times were similar, 3.225s on CLI and 6.13 in Finder. Let me fire up the old MBP and do the same test on the SATA SSD.
Well, that was an interesting result for sure... I just had Finder freeze up on me, using 99% CPU, while I was *creating* the 100k files *on the command line*. I could understand that if I had the folder open in Finder while creating the files, but I didn't.
So, the CLI delete took 3.12 seconds, while deleting via Finder took 5.92. A much faster result than I'm used to, but then, it was a single level deep; though Finder did take nearly twice as long. Time to test multiple levels of nesting, like I mentioned previously. Also, I did know about CMD-Delete. That's how files get moved to the trash on my system. It's been that long since I've deleted files via Finder; I actually forgot how for a moment. Shift-CMD-Delete gives me an error chime and does nothing. What hidden configuration or 3rd-party utility are you using to enable the key combinations you mentioned?
For reference, here's the bash script I used to create the files:
#!/bin/bash
mkdir bigdir
for i in `seq 1 100000`;
do
echo '' > bigdir/$i
done
Didn't know about CMD-Delete or Shit-CMD-Delete, actually. Never needed to know, I've been deleting things from the CLI for much longer than I've been using a Mac. I also haven't tried deleting 10k+ files in Finder in the couple of months I've had a Retina MBP; my previous MBP had a SATA SSD that could max out the bus, though, and started bogging down around 10k and would crap out around 50k. That was a quad core with 16GB of RAM (where Apple would only support configurations up to 8GB, so I imagine the problem would be worse for users who limit themselves to what Apple sells).
In fact... hell, let me put your claims to the test.
How else does the average luser know thet bouncingbewbiez.gif.exe is a virus?
Not entirely true. Let's say you have a PNG file, image.png, with the executable bit set. Doublie-clicking it in Finder will open it in your image viewer. Renaming it to image.png.app or image.app, then trying to open it, will cause OSX attempt to execute it, then complain that it is not supported. Removing the extension, then trying to open it, will cause OSX to attempt to execute it in a shell if the executable bit is set, or scan for a recognizeable header to determine file type and open the correct application, if the executable bit is not set. In only one of those cases is the extension optional, and even then, it's useful; for example, you can set .jpg to open in a viewer and .jpeg to open in an editor, so you can easily identify working copies and have them automagically open in your editor; the same works for pretty much any file type, provided that either your viewer or editor can be configured to recognize and handle alternate extensions.
You also never actually know whether that image (or at least, the file you *think* is an image) is actually an image. Using the file extension hints to you that it is an image and tells the system to treat it as one, so you don't end up with a file that looks like an image, but actually formats your hard drive. If your file has the wrong extension, you change it in Finder or on the command line, just as you would change it in Explorer or on the command line in Windows. As an added bonus, there is no executable file extension; it's a permission that gets set, and the file extension still takes precedence. That is, if you set notanimage.jpg to be executable, then try an open it in Finder, it'll open it in your image viewer, ignoring the execute bit entirely; only when you remove the extension does it actually attempt to execute.
The way OSX does it is correct, IMO. And 4 years ago I never thought I'd be saying that.
We were of the same mind right up until your last sentence. Finder is good for browsing, shit-slow for copying or deleting more than a handful of files, and doesn't actually delete, which adds an extra step (emptying the trash). Because of this, I find that Finder is better utilized for browsing, especially media collections, while the command line is often faster for manipulation. Try deleting a folder with several subfolders, several levels deep, and over 10k files; make a copy first, so you can do it in Finder, then again on the command line. Time them. In fact, make two copies, one from Finder and one from the CLI, and time those, too.
Of course, if you're routinely deleting one or two files at a time, or just a handful here and there, then the difference is immeasurable, if there even is one; but if you have to do any sort of bulk deletes, Finder will choke on the file list[1]. Of course, you still have to manually empty the trash before the file actually gets deleted; this more than doubles the time an actual delete operation requires; one pass to move files to the trash, another pass to actually delete. It's even worse on network volumes, since those are much higher latency, and often much slower, to begin with.
[1] - Admittedly, so well rm, but it takes a lot more files and will at least tell you about the condition and exit gracefully, so you can break the operation into smaller chunks or use find's -exec option instead, whereas Finder will just sit there, frozen, and prevent you from ejecting the disk or even rebooting gracefully
Headphones are not earbuds. :)
Oh, and sorry 'bout ur mum.
I may do so at some point in the future, since there seems to be some interest in it. I would want to run anything like that by an attorney first, since I'm fairly certain it does constitute legal advice.
And if I don't want to use a GUI? Seems your steps should still be applicable to the CLI. That being said, you're rewriting history when doing that, and that is considered a huge no-no when using Git, especially when you have a team of developers. You'll have a local branch without the commit you just skipped over, but everyone else will still have that commit in their history, meaning they'll all still have the "bad" code. It's probably fine if you're the sole developer, but it's generally not advised to assume that will always be the case. Methinks I'll not follow your advise on this.
Go a little farther west and you can walk into a 7-11 and walk out with a dozen anonymous phones.
And my comment was about clients making changes to the spec. It doesn't matter how good your estimate is or how perfect your project plan is if the client decides to change the project after work has begun. You can refuse the changes, but they can also refuse to pay. You can give up the job, but hey, you're still not getting paid if you do that. The best hope you have is for the client to understand that their change, no matter how trivial it may seem, means more work for you and, therefore, more cost for them.
Or, to put it another way, go ahead and estimate the cost of that paint job. Then build a project plan for it that holds up in the situation I described. I'll be pricing you against a few local shops who are known for quality work; you high has to be competitive or I'll go elsewhere.
This isn't as much of an issue when your client is internal to the company, but that was clearly not the case in my analogy.
And yet, you still get know-nothings who insist that you're wrong and want to push forward anyway. Thankfully, for the ones I've encountered, money is not an object and they're more than happy to pay for the work to be redone. I had one client try and argue the point and I told them very plainly that their options were to continue the project as originally detailed, take the incomplete work, as-is, or pay for the changes they were requesting. Which option they took is irrelevant, but I'll say the project got done and I got paid.
That doesn't negate the fact that people will still insist on changes, no matter how careful you are in communicating issues you find in their requirements and getting clarification before starting work. You're absolutely right, though; many people don't know how to handle it when it happens.
My example was meant to highlight the fact that a single word change in the spec can mean having to redo work. No matter how easy it is to *undo* the work (in the case of programming, it's often much easier than in my analogy, but this is not always the case), the fact remains that the work must still be redone. Just because my analogy did not include having done work that needs to be kept, subsequent to having done work that needs to be redone, doesn't make my honest curiosity irrelevant; and your response seems to indicate that, save for having planned for that very occurance, it is indeed not possible (and even with planning, only maybe, if you're willing to create a new branch for nearly every commit... and you're lucky).
Honestly, I was hoping you'd tell me it was easy. This is one of those instances where I'd jump for joy while screaming at the top of my lungs "I WAS WRONG! I WAS WRONG! THANK YOU, LORD, I WAS WRONG!" Not that I have a use for it at the moment, but it's come up in the past and I'm sure it'll come up again in the future.
You still end up rewriting code. Version control is great for many things, including rolling back to a previous point in time, but please tell me how to undo something I did last week without rolling back everything I've done since. I'd actually really like an answer to that, with regards to Git, if you've got one.
Well, yes, if a car was a data construct. Way to miss the point.
;)
Or were you going for funny? in that case, yeah I'll grant you that.
You've got a few years on me, actually! I've just spent a little over 4 years working for a guy who's made some real boner mistakes and got to learn form him. :)
I'll drop you an email in the AM, I really should be asleep right now.
I have a project that was due last week that I haven't started on yet. I got the deposit check the day I handed over the SoW, but didn't get the signed SoW back until last week, 6 weeks later. As per the terms of the SoW, I'll reschedule it when I find time.
Most of the delays I encounter are caused by someone else; either the need to refactor someone else's shit code (that I wasn't allowed to review before providing an estimate, of course), delayed approval for the work, delayed access to resources, any number of external forces. Very rarely do I exceed my estimated *hours* for a project unless changes are requested (but then I'm not exceeding the estimate, either, since I make the client either agree to a new estimate or accept a refund of any portion of their deposit not already applied to the hours I've worked), but all too often I find myself completing projects well past their due date because some resource wasn't made available to me until after that date had lapsed.
Fortunately, I foresaw that unforeseen things would happen when drafting the boilerplate language of my SoW and covered all of those cases. I go over the entire SoW with my clients before starting a project and make sure they know what the triggers are for a re-quote, what will cause the project to be delayed, and under what circumstances they're entitled to a refund of any deposit they pay (e.g. if they back out of the project once I've started work, I'm deducting my hours from that). As a result of that, and perhaps a bit of luck, I haven't had any disputes over project scope, budget, or timeline, and the one client I did have back out of a project simply said they no longer had the budget (they were being sued) and told me to hold on to the remainder of their deposit as they'd be back to finish the project after they lawsuit ended, hinting that, even if that didn't happen, the small sum would make no difference going forward (of course, I'm sitting on that money for now, and if they fully back out of the project I'll insist that they either accept the refund or sign a document releasing the funds to me).
That was one thing that really pissed me off when I was working for someone else; I had no control over external interruptions or delays and it was usually the person interrupting and delaying me who was holding me accountable for all of them. I'm not out to scam anyone, but I always felt like I was when dealing with my previous employer.
He may have been able to write more maintainable, more stable, better tested, and altogether cleaner code, given what he asked. Possibly in half of his worst-case estimate of 2 years. In the long run, the crap that needed to be slapped together to get the project "done", in 4x the time he was allotted, will end up costing the company more than giving him what he asked for in order to do it right. You must be an MBA.