Unix Haters' Club
-
last two decades!!
Gross misunderestimation.
Well.. the OS could allow multiple files of the same name with different Content-Type metadata.
"Okay, I'm done. Now let me just rerender it and print it out."
rm thesis
"...oh fuck"
-
You should have listened to @Blakeyrat.
Command Line Interfaces are not secure and should never be used.
If you used a GUI, you would have seen the difference between your LaTeX file and your PDF and such a mistake would not have happened.
-
Gross misunderestimation.
Hey, the NWO only pays me to troll back to the first Bush Administration.
"Okay, I'm done. Now let me just rerender it and print it out."rm thesis"...oh fuck"
Obviously "rm" just needs to be modified to take a Content-Type. To save typing, we'll reduce it to an integral enum, encoded as a letter and passed as a flag. For example to delete video/mp4 just do:
rm -m thesisOf course, some of the types will conflict with normal "rm" flags, so we just add a backslash to escape. To delete a file containing R source code, simply do:
rm \-r thesisSimple!
-
You should have listened to @Blakeyrat.Command Line Interfaces are not secure and should never be used.If you used a GUI, you would have seen the difference between your LaTeX file and your PDF and such a mistake would not have happened.
Meh, what if you're managing tens of thousands of servers? I'm not one of those idjits saying CLI is bestest for everything, but sometimes it is more convenient, even in Winders.
-
You don't write tens of thousands of theses.
-
You don't write tens of thousand of theses.
Are you really a dame, as your username suggests?
Or is it short for "a lice interface"?
And, yes, I have written tens of thousands of theses. It's just that the "Journal of Neo-Confederate White Supremacy" refuses to publish them any more, the liberal bastards.
-
I just wanted to make fun of someone's CLI aversion.
Although, I pretty much never use a CLI for file management myself.
-
I just wanted to make fun of someone's CLI aversion.Although, I pretty much never use a CLI for file management myself.
Hmm.. reluctance to reveal gender == male posting with a female avatar. Disgusting!
I'm not CLI-averse. A lot of tools I write are CLI. I do think people who think it's better for everything are idiots, though.
-
Hmm.. reluctance to reveal gender == male posting with a female avatar. Disgusting!
I wanted to stay on topic. Not to forget, the two alternatives you gave were not mutually exclusive.
I am female.
@morbiuswilters said:I'm not CLI-averse. A lot of tools I write are CLI. I do think people who think it's better for everything are idiots, though.
I actually meant blakey. And I agree, CLI and GUI are better at different things in different situations. And I think we can agree that we're glad that today's UNIX systems have GUIs available, even if they often suck.
-
So, obvious follow up question. What do other DVCSes do that you believe to be better?
Fossil maintains its own idea about what branch you're on; that identity is independent of the (shared) labelling that you attached to the branch. When you pull new artifacts in (i.e., find out what your current favourite upstream has been up to) you don't move at all. You can also update your checkout to be at the newest point with a particular labelling, which is convenient when working on a branch that is shared. (Private branches aren't ever pushed out; git effectively almost always works with private branches.)
The only point where fossil moans at you is when you're committing to a branch (and not creating a new branch with the commit) where the current state is not a branch tip. And you can force it to do it anyway. But you get the same situation happening if two people commit to the same branch at the same time (and necessarily so in any DVCS); two branches in the version tree with the same branch label. That's when someone has to merge things and get stuff sorted out. Fortunately, fossil's built-in UI (delivered as HTML using a local tiny web server) means that everyone's got a graph view of the commit tree that is spiritually similar to the github network view. Or perhaps to the gitk client. Sorting out what happened (and labelling the other branch as “don't use”) isn't too hard.
I turn on auto-sync in my fossil repositories, which makes it a bit more SVN/CVS like, but that's OK because the team isn't too large. I don't have to optimise for developing the Linux kernel…
-
Darcs does not have a branch command. You just clone the entire repository[1] into another directory. This is more usable for, say, compiled languages.
WTF. I don't see how this is more usable. It frankly seems crazy to me. At least now I know that I never want to use Darcs.
The point is, Darcs can keep my keys and database configuration versioned (locally) without having to share that versioning information with another repository.
Hmm...I can see how that would be useful. I guess I'd use a separate (private) repo for something like that and configure my build or deployment to work together somehow.
-
So, maybe instead of trying in vain guess the type, like the hapless carnie working the "Guess Your Weight" booth at a feminist conference, we should just rely on some highly-visible piece of metadata that is user-controlled.
I recommend just using very strong electromagnets. It solves most of these problems. Fire can also work in a pinch.
-
Yes there is an excuse. The excuse is: Unix and Linux filesystems suck shit, but they run the Internet, so fuck everybody else.
-
Nope. Unix systems have pretty much always had the "file" command1, which examines file contents to see what they actually contain.
Oh yeah and obviously there's a set standardized way to do this, and a registry to keep track of all those types, and it's not just a couple dumbshits sitting in a basement cowboy coding to shit. Right?
Determining file type by extension is pretty much verboten under Unix;
First of all, I'm pretty sure that's a lie considering every Linux/Unix webserver I've ever seem uses file extensions all over the fucking shit, and don't say that's "IE's fault" when your file extension is .php and it serves up text/html.
Secondly, identifying a file by extension is "verboten" (Goddamned you people talk like assholes), but identifying a file by just looking at some random bytes in it and seeing a value that might be expected maybe, and if a new file format comes along what now? That's ok? Fuck.
The reason we're stuck with fucking file extensions is, again, that fucking pox on the software industry, fucking Microsoft software; designed, as you say, by "shitty dumbasses".
Oh fuck off. I'm not going to give Microsoft a pass, but the reason file type metadata didn't pick up is purely Linux/Unix fault. The instant a file has to go over the Internet, it has to be coped-with by *nix filesystems, and those filesystems had NO WAY of preserving MacOS resource forks or NTFS alternative data streams. Every non *nix filesystem, including Microsoft's, was fucked by this.
Internet protocols like email, FTP, don't even provide a provision for sending meta-data. Because who would want to do that? Only Unix/Linux users are on Internets and we don't need it because we have the obviously superior system of some fat guy in a basement saying "if byte 63 is a 7D, it must be a gif!"
Sorry, dude, but no matter how awesome Mac OS Classic was, hardly any of it persisted until the present day. So we're stuck with file extensions or scanning the file to try to guess the type. It should be obvious which is better.
Yeah. The better option is the one that's long since dead, since IT is a ball of bullshit and it's getting worse ever year.
Partially because people like Tufty exist.
-
Indeed. But that's all file extensions allow you to do. After all, you can't trust randomly editable metadata.
That's why MacOS made it so you had to go waaay out of your way to change the file type field, requiring ResEdit, which generally wasn't even installed.
-
Hell, "file type" is not really a file attribute - just a hint to the OS/shell as to which program should open the file.
That's why MacOS kept two bits of information: 1) what is this file? 2) what program is the default to open it?
The more time passes, the more amazed I am at how well-designed Classic Mac was.
-
Yeah. The better option is the one that's long since dead, since IT is a ball of bullshit and it's getting worse ever year.
Partially because people like Tufty exist.
Tufty: Ruining everything since 1989
-
The only one that makes any sense, in the presence of file systems that allow multiple names for files, is proper metadata, not arbitrary naming schemes.
Weren't you just saying like 3 posts ago that the Linux auto-guessing bullshit was genius and so much better than everything and you wanted to marry it?
-
"Delete all header files"? Simple, just write rm *.h *.hpp and that's all it takes.
But you can't do that, because "rm" is a Linux command and Tufty told me that file extensions like ".h" are VERBOTEN!!! VERBOTEN!!!!!
And Tufty would never lie to us.
-
Well.. the OS could allow multiple files of the same name with different Content-Type metadata. But wotta mess.
Ok MacOS didn't pull that shit.
But here's the thing: the brilliant MacOS system didn't prevent you from adding file extensions if you wanted. So you could still just name the PDF copy ".pdf". Or you could name it, "this file is a PDF!!!!!!" or whatever.
-
Meh, what if you're managing tens of thousands of servers?
AppleScript. VBScript. JScript.
Solved problem. Solved for decades.
-
Using extensions is entirely up to the user and many people tend to do it because it is user-friendly.
It's like using hungarian notation in Windows Forms.
-
It's like using hungarian notation ...
is that apps or systems Hungarian?
in Windows Forms.
Ah. Systems. Not user friendly then.
-
Tufty disagrees. Tufty says they are VERBOTEN!!!
Who are we to argue with Tufty.
-
-
Has anyone else noticed that blakeyrat seems much more irritable and angry when morbiuswilters is around?
-
Sounds like confirmation bias to me.
-
Partially because people like Tufty exist.
Although I'm amused, and, I'll admit, a little flattered, to become the new target of your ire, I think you may find it's somewhat misdirected; I detest the concept of file extensions as much as you, perhaps even more radically so. 'cause I'm not only a classic mac geek, but also a Newton geek. HFS resource forks were a start, but they were nothing compared to what Newton did.
@blakeyrat said:the more amazed I am at how well-designed Classic Mac was.
There was a lot that was wrong with it, but there was an awful lot more that was extremely good. Unfortunately, a lot of the good stuff got lost in the migration to OSX.
-
It all got lost. There's no goddamned variety in IT. There's two OSes that consist of millions of tiny files. Everything else is dead.
-
Oh fuck off. I'm not going to give Microsoft a pass, but the reason file type metadata didn't pick up is purely Linux/Unix fault. The instant a file has to go over the Internet, it has to be coped-with by *nix filesystems, and those filesystems had NO WAY of preserving MacOS resource forks or NTFS alternative data streams. Every non *nix filesystem, including Microsoft's, was fucked by this.
Windows shittiness about file types predates its TCP stack.
Meanwhile, Unix did have a registry of file types maintained by the likes of AT&T and SCO.
-
Is file types really something to be angry about?
Filed Under: where's the stupid questions thread, anyways?
-
I like to poke the bear. If he gets angry over being stupid and wrong, that's his problem.
-
I have no problem poking bears. I'm just amazed at what qualifies as a poke.
-
Ask Facebook. Any old AJAX request practically qualifies.
-
That's why MacOS kept two bits of information: 1) what is this file? 2) what program is the default to open it?
Okay, there's a good use-case for "I want to open my photos in a photo viewer, and my icon resources in a pixel editor, even if they're internally the same type". But then, why store the "what is this file" information at all? As I said, it's hardly useful to know what the internal representation is - for a standard user, both pieces of data are equivalent (with the other possibly conveying more information). The fact that "it's a standard-conforming .png file" doesn't matter at all.
But here's the thing: the brilliant MacOS system didn't prevent you from adding file extensions if you wanted. So you could still just name the PDF copy ".pdf".
And I fail to see the case in which you wouldn't want to do that. And since you're doing it anyway, it's pretty much as well that the OS could use the extension to infer the file format (as for actual content type, see above).
Still, it probably wasn't a bad idea, but it kind of verges on Occam's razor to me.
Oh fuck off. I'm not going to give Microsoft a pass, but the reason file type metadata didn't pick up is purely Linux/Unix fault.
I think the reason is mostly a) the fact that encoding it in filenames simply works, and b) that there was an OS called CP/M back in the Dark Ages, and it all went downhill from here.
-
But then, why store the "what is this file" information at all? As I said, it's hardly useful to know what the internal representation is - for a standard user, both pieces of data are equivalent (with the other possibly conveying more information).
So that if you send it to a computer that doesn't have the first computer's photo viewer. Say you use Photoshop Elements, and I use Picasa, the photo still opens just fine.
The logic worked like: "ok, look for the app with that Creator Code... not present on system. Ok, look for apps that can open file type Type Code. Here's a list of three. Let's ask the user which of the three he wants to use to open this file."
If I open the Photoshop Elements file in Picasa, make a change, then save it, Picasa sets itself as the Creator Code, and from then on it'll just open in my preferred editor by default. The format of the file never changed.
And I fail to see the case in which you wouldn't want to do that.
The case it's in response to, the "having two files that are the same except type in the same folder" problem I was replying to.
I think the reason is mostly a) the fact that encoding it in filenames simply works, and b) that there was an OS called CP/M back in the Dark Ages, and it all went downhill from here.
It's not "works" vs. "not works", it's "shitty" vs. "really unbelievably shitty".
What's frustrating to people like me, who have actually used a lot of OSes that had a lot of good ideas, is that the better stuff doesn't tend to actually spread anywhere. It doesn't matter how great MacOS's system is if: 1) nobody else adopts it, 2) when computer interchange formats are built they don't account for it, and 3) the OS isn't successful.
- is the biggest culprit here, as even the later versions of MacOS were spending as much time looking at file extensions as they were looking at Resource Forks.
-
But here's the thing: the brilliant MacOS system didn't prevent you from adding file extensions if you wanted. So you could still just name the PDF copy ".pdf". Or you could name it, "this file is a PDF!!!!!!" or whatever.
Oh, it allowed spaces in file names? Seriously?!
-
Yes. And every character that is disallowed in Windows, except colon (:).
You could write dates the way people write dates on paper! "8/21/2014.txt" INCREDIBLE!
-
How do you specify the name on the command line? You have to escape the slashes or something? That sounds terrible.
-
So that if you send it to a computer that doesn't have the first computer's photo viewer.
Okay, that makes sense, though still open to weirdness (say I have Picasa installed, but hardly use it, yet the photos you send me keep opening in your preferred program instead of mine).
The case it's in response to, the "having two files that are the same except type in the same folder" problem I was replying to.
Yes, that's when you'd put an extension on. The point is, I don't see an actual, valid reason for not putting an extension on a file. Okay, the name looks a tiny bit uglier, but aside from that?
What's frustrating to people like me, who have actually used a lot of OSes that had a lot of good ideas, is that the better stuff doesn't tend to actually spread anywhere.
Well, surprise. Why would I want to switch to those shiny new features, and have to get a whole new toolkit to work with them, when stuff I have is just fine?
Even if you don't think like that, most people do. They just don't care about that tiny bit of edge using the feature possibly gives them, they see the necessity to drop a part of their current workflow and learn a new thing.
-
The point is, I don't see an actual, valid reason for not putting an extension on a file. Okay, the name looks a tiny bit uglier, but aside from that?
The nice thing about extensions is that they're easy to see. You don't need any special tooling or super duper UI derps about displaying them. Unless you're stuck with Microsoft's defaults, of course. :facepunch:
-
Okay, that makes sense, though still open to weirdness (say I have Picasa installed, but hardly use it, yet the photos you send me keep opening in your preferred program instead of mine).
So either open them using Picasa's File menu, or right-click and do "Open With..." which was there from like System 8+.
-
The nice thing about extensions is that they're easy to see. You don't need any special tooling or super duper UI derps about displaying them. Unless you're stuck with Microsoft's defaults, of course.
So "worse is better", basically?
I kind of torn - extensions remind me of Hungarian notation (brings the nightmares back), but the alternative is having a strongly, strictly typed file system. Hmmmmm...
-
So "worse is better", basically?
Maybe a little worse. But when you get to Microsoft worse, worse really is worse.
-
No, the alternative is simply storing the file type separately from the name. It could still be stored as a simple string, so it would be exactly the same in practice (you could open JPG files in notepad if you want).
In fact, you could just store the extensions the way we do now, and show it grayed out next to the file name, but not let you edit it unless you right click and select the option to do that. This would have most of the advantages of separate metadata (i.e. not being accidentally changed), while being compatible with current software and "easy to see".
Currently it does something similar: it hides extensions and shows a "file type" column. This however has a few problems:
- You can't immediately see the file type by visually scanning the file names.
- It's an abstraction and usually ambiguous (both JPG and PNG files are just "Image files" even though they are quite different formats)
- It can't be changed anywhere.
Or alternatively you could store it in a separate metadata field, maybe with a different format (MIME types?), and "translate" it to a regular file extension when copying it to a filesystem that can't handle that metadata.
-
unambiguous bit of metadata
I don't want to do a blakeyrant here, but... I don't think you've been reading what's being said here.
-
highly-visible piece of metadata that is user-controlled
Controlled by users who don't know what it means, as part of something they edit routinely. What could possibly go wrong?
-
Yes there is an excuse. The excuse is: Unix and Linux filesystems suck shit, but they run the Internet, so fuck everybody else.
You're funnier when your rants are fundamentally correct. When you're just plain wrong because you're ignorant of the subject it's boring.
-
Say what?
Well, for one, they're an optional component. And for two, when were they added to the kernel?
Unix almost always just uses the stupid "guess the mime type" heuristic.
-
Internet protocols like email, FTP, don't even provide a provision for sending meta-data
I can't find a more digestible version of this in my ten-second search: RFC 2822. It's only 13 years old. The RFC it supercedes is over thirty. This is the format of HTTP message bodies and MIME email. Stop being ignorant.
FTP is broken for many reasons, lack of metadata doesn't even make my list. Stop using broken protocols.
