So I decided to try to update part of my toolchain...
-
@Gąska I think you're starting to realize that you're recreating a more complicated version of what we already have but your conscious mind hasn't caught on yet.
For instance, why wouldn't "making command line smarter" fix a lot of the current issues without all the extra complications you've imagined?
-
@boomzilla said in So I decided to try to update part of my toolchain...:
@Gąska I think you're starting to realize that you're recreating a more complicated version of what we already have but your conscious mind hasn't caught on yet.
I think you still haven't bothered to read any of my posts in this entire topic.
For instance, why wouldn't "making command line smarter" fix a lot of the current issues without all the extra complications you've imagined?
Because, see the previous thread.
-
@Gąska said in So I decided to try to update part of my toolchain...:
@boomzilla said in So I decided to try to update part of my toolchain...:
@Gąska I think you're starting to realize that you're recreating a more complicated version of what we already have but your conscious mind hasn't caught on yet.
I think you still haven't bothered to read any of my posts in this entire topic.
Yes, and you think you're fixing a problem with filesystems.
-
@boomzilla that you think I'm talking about filesystems is the perfect proof that you haven't actually read any of my posts.
-
@Gąska said in So I decided to try to update part of my toolchain...:
@boomzilla that you think I'm talking about filesystems is the perfect proof that you haven't actually read any of my posts.
Nervertheless I read your posts.
What do you call these systems of files then?
-
@boomzilla the ones I'm talking about? The operating system. Specifically, file access API.
-
@Gąska said in So I decided to try to update part of my toolchain...:
@boomzilla the ones I'm talking about? The operating system. Specifically, file access API.
So you're actually still using the same filesystems we have today? I totally didn't get that from your posts.
-
@boomzilla the filesystem is irrelevant. A brand new one would probably be a better choice for performance reasons, but in the end any filesystem will do, since the OS would abstract it all away. It's how the applications access the files that matters.
-
@Gąska every single thing I said about your idea applies. This last go around was just pendantic wankery, but I appreciate the pedantic dickweed loophole you tried to use to escape.
-
@boomzilla said in So I decided to try to update part of my toolchain...:
@Gąska every single thing I said about your idea applies.
And so does every single reply I gave you.
-
@Gąska said in So I decided to try to update part of my toolchain...:
@boomzilla said in So I decided to try to update part of my toolchain...:
@Gąska every single thing I said about your idea applies.
And so does every single reply I gave you.
I see that you're still clinging to the belief that if only people read your ideas they'll see how brilliant you and your ideas are. That's a bold plan.
-
@boomzilla said in So I decided to try to update part of my toolchain...:
That's a bold plan.
Downright courageous.
-
@boomzilla said in So I decided to try to update part of my toolchain...:
@Gąska said in So I decided to try to update part of my toolchain...:
@boomzilla said in So I decided to try to update part of my toolchain...:
@Gąska every single thing I said about your idea applies.
And so does every single reply I gave you.
I see that you're still clinging to the belief that if only people read your ideas they'll see how brilliant you and your ideas are.
No, I'm just clinging to the belief that only people who actually have something to say are to be listened to. For the most part, you've only made generic statements that didn't actually contain any information. Pointless bickering devoid of substance. Your point about makefiles is actually very good (too bad @HardwareGeek d you on that by an entire day!) - if you focused less on your hallucinations that people hate naming things and want to replace them with meaningless numbers, and more on those good points, we'd have a much more productive conversation.
-
@Gąska said in So I decided to try to update part of my toolchain...:
You can try to organise things in a more arbitrary fashion by tagged collections and so on, but that's actually beyond what almost all users will understand (except for the more talented of programmers).
Explains why Gmail was such a failure. Oh wait.
And Google Drive!
-
@Gąska said in So I decided to try to update part of my toolchain...:
Pointless bickering devoid of substance.
That's WTDWTF! \o/ \o/ \o/ Go us!
-
@Gąska said in So I decided to try to update part of my toolchain...:
@boomzilla said in So I decided to try to update part of my toolchain...:
@Gąska said in So I decided to try to update part of my toolchain...:
@boomzilla said in So I decided to try to update part of my toolchain...:
@Gąska every single thing I said about your idea applies.
And so does every single reply I gave you.
I see that you're still clinging to the belief that if only people read your ideas they'll see how brilliant you and your ideas are.
No, I'm just clinging to the belief that only people who actually have something to say are to be listened to. For the most part, you've only made generic statements that didn't actually contain any information. Pointless bickering devoid of substance. Your point about makefiles is actually very good (too bad @HardwareGeek d you on that by an entire day!)
I was building on his statement you retard.
- if you focused less on your hallucinations that people hate naming things and want to replace them with meaningless numbers, and more on those good points, we'd have a much more productive conversation.
Oh, now you're acting like you didn't read my posts because you can't recognize your terrible ideas. How novel.
-
@boomzilla said in So I decided to try to update part of my toolchain...:
@Gąska said in So I decided to try to update part of my toolchain...:
@boomzilla said in So I decided to try to update part of my toolchain...:
@Gąska said in So I decided to try to update part of my toolchain...:
@boomzilla said in So I decided to try to update part of my toolchain...:
@Gąska every single thing I said about your idea applies.
And so does every single reply I gave you.
I see that you're still clinging to the belief that if only people read your ideas they'll see how brilliant you and your ideas are.
No, I'm just clinging to the belief that only people who actually have something to say are to be listened to. For the most part, you've only made generic statements that didn't actually contain any information. Pointless bickering devoid of substance. Your point about makefiles is actually very good (too bad @HardwareGeek d you on that by an entire day!)
I was building on his statement you retard.
Didn't look like it. I thought you just haven't read his posts and weren't aware you're repeating after him almost verbatim. I mean, you didn't really add anything new, and my response to him covers everything you said as well.
- if you focused less on your hallucinations that people hate naming things and want to replace them with meaningless numbers, and more on those good points, we'd have a much more productive conversation.
Oh, now you're acting like you didn't read my posts because you can't recognize your terrible ideas. How novel.
What?
-
@Gąska said in So I decided to try to update part of my toolchain...:
@boomzilla said in So I decided to try to update part of my toolchain...:
@Gąska said in So I decided to try to update part of my toolchain...:
@boomzilla said in So I decided to try to update part of my toolchain...:
@Gąska said in So I decided to try to update part of my toolchain...:
@boomzilla said in So I decided to try to update part of my toolchain...:
@Gąska every single thing I said about your idea applies.
And so does every single reply I gave you.
I see that you're still clinging to the belief that if only people read your ideas they'll see how brilliant you and your ideas are.
No, I'm just clinging to the belief that only people who actually have something to say are to be listened to. For the most part, you've only made generic statements that didn't actually contain any information. Pointless bickering devoid of substance. Your point about makefiles is actually very good (too bad @HardwareGeek d you on that by an entire day!)
I was building on his statement you retard.
Didn't look like it. I thought you just haven't read his posts and weren't aware you're repeating after him almost verbatim. I mean, you didn't really add anything new, and my response to him covers everything you said as well.
That was your funniest reply yet because you admitted that you were doing exactly what I've been saying you were doing. Maybe you should read your posts?
-
@boomzilla what?
-
@Gąska exactly! Now feign incomprehension of simple English to hide your embarrassment. Brillant!
-
@boomzilla no, really. That post makes zero sense. You're saying that I didn't read... my own posts? WTF man? Where did that even come from? And how is that connected to your remarks on makefiles?
To me, it looks like you ran out of things to say and have resorted to Rhywdenesque tactics of mumbling random words without rhyme or reason, hoping to make the other person's head spin and them giving up on trying to deal with you, after which you declare victory.
-
@Gąska said in So I decided to try to update part of my toolchain...:
To me, it looks like you ran out of things to say and have resorted to Rhywdenesque tactics of mumbling random words without rhyme or reason, hoping to make the other person's head spin and them giving up on trying to deal with you, after which you declare victory.
This is because you still haven't realized that you're just recreating the current situation but more complicated. You said that one has to query each level instead of being able to statically reference it using a path. And you've renamed it from "path" to "hierarchical directory," which confuses your overly literal vocabulary and prevents you from seeing that from an abstract point of view they're the same thing.
So now it's also funny that you accuse me of Ryhdwhenism when you're doing exactly the sort of thing he often does.
-
@boomzilla said in So I decided to try to update part of my toolchain...:
@Gąska you read me.
I'm now picturing you as a 13 year old with a bow and arrow...
-
@boomzilla said in So I decided to try to update part of my toolchain...:
You said that one has to query each level instead of being able to statically reference it using a path.
Not exactly. You need to query each level when traversing. When you don't know what the contents are. When you want to access file/directory you already know about, you use its ID.
And you've renamed it from "path" to "hierarchical directory," which confuses your overly literal vocabulary and prevents you from seeing that from an abstract point of view they're the same thing.
Path is a sequence of fragments. When you don't have sequence of fragments, you don't have path. And this is a very important distinction, because the problems we currently have with programs doing their things on the wrong files, aren't problems with hierarchies - they're problems with paths. When you have hierarchies without paths (at least at file access API level), those problems go away even though you haven't got rid of hierarchies. This is not language pedantry, this is important issue.
-
@Gąska said in So I decided to try to update part of my toolchain...:
@boomzilla said in So I decided to try to update part of my toolchain...:
You said that one has to query each level instead of being able to statically reference it using a path.
Not exactly. You need to query each level when traversing. When you don't know what the contents are. When you want to access file/directory you already know about, you use its ID.
So all that talk about "people never need to know about the ID" was bullshit?
And you've renamed it from "path" to "hierarchical directory," which confuses your overly literal vocabulary and prevents you from seeing that from an abstract point of view they're the same thing.
Path is a sequence of fragments. When you don't have sequence of fragments, you don't have path. And this is a very important distinction, because the problems we currently have with programs doing their things on the wrong files, aren't problems with hierarchies - they're problems with paths. When you have hierarchies without paths (at least at file access API level), those problems go away even though you haven't got rid of hierarchies. This is not language pedantry, this is important issue.
Except that you're ignoring many ways in which people deal with these things and getting right back around to the same exact problem. Scripts and makefiles and config files being the most obvious here [to me]. Unless we're actually forcing people to know and use those IDs, which seems like it couldn't possibly work once you want to share things across systems (as previously pointed out upthread).
-
@boomzilla said in So I decided to try to update part of my toolchain...:
@Gąska said in So I decided to try to update part of my toolchain...:
@boomzilla said in So I decided to try to update part of my toolchain...:
You said that one has to query each level instead of being able to statically reference it using a path.
Not exactly. You need to query each level when traversing. When you don't know what the contents are. When you want to access file/directory you already know about, you use its ID.
So all that talk about "people never need to know about the ID" was bullshit?
You as in the program.
And you've renamed it from "path" to "hierarchical directory," which confuses your overly literal vocabulary and prevents you from seeing that from an abstract point of view they're the same thing.
Path is a sequence of fragments. When you don't have sequence of fragments, you don't have path. And this is a very important distinction, because the problems we currently have with programs doing their things on the wrong files, aren't problems with hierarchies - they're problems with paths. When you have hierarchies without paths (at least at file access API level), those problems go away even though you haven't got rid of hierarchies. This is not language pedantry, this is important issue.
Except that you're ignoring many ways in which people deal with these things and getting right back around to the same exact problem. Scripts and makefiles and config files being the most obvious here [to me].
Scripts are just ad-hoc programs - whatever you can force C++ folks into, you can force script folks as well.
We've already covered makefiles.
I still don't know how config files and file paths are at all connected. Unless you're going for "you cannot put a path in config file when you don't have a path" self-defeating prophecy. Can you show a specific, high-level use case from end user's POV that would show the problem you have in mind?
-
@Gąska said in So I decided to try to update part of my toolchain...:
@boomzilla said in So I decided to try to update part of my toolchain...:
@Gąska said in So I decided to try to update part of my toolchain...:
@boomzilla said in So I decided to try to update part of my toolchain...:
You said that one has to query each level instead of being able to statically reference it using a path.
Not exactly. You need to query each level when traversing. When you don't know what the contents are. When you want to access file/directory you already know about, you use its ID.
So all that talk about "people never need to know about the ID" was bullshit?
You as in the program.
And you've renamed it from "path" to "hierarchical directory," which confuses your overly literal vocabulary and prevents you from seeing that from an abstract point of view they're the same thing.
Path is a sequence of fragments. When you don't have sequence of fragments, you don't have path. And this is a very important distinction, because the problems we currently have with programs doing their things on the wrong files, aren't problems with hierarchies - they're problems with paths. When you have hierarchies without paths (at least at file access API level), those problems go away even though you haven't got rid of hierarchies. This is not language pedantry, this is important issue.
Except that you're ignoring many ways in which people deal with these things and getting right back around to the same exact problem. Scripts and makefiles and config files being the most obvious here [to me].
Scripts are just ad-hoc programs - whatever you can force C++ folks into, you can force script folks as well.
We've already covered makefiles.
Yes, by doing exactly what I said.
I still don't know how config files and file paths are at all connected. Unless you're going for "you cannot put a path in config file when you don't have a path" self-defeating prophecy. Can you show a specific, high-level use case from end user's POV that would show the problem you have in mind?
Wow. I'm talking about referring to a file from within a config file. Not really different than what you'd do in a makefile.
The answers here for how to do this is to either still have a path system or to use a combination of tags, which is going to have similar problems to a combination of subdirectories that make up a path.
You keep saying "I've covered makefiles" and I agree. It's just that you've proved me right when you did that and every time you tell me that you covered them.
-
@Gąska Here's an honest question, based on something I do regularly.
So I'm writing an HTML file by hand, say in Visual Studio Code. I want to link it to a CSS file and include images. But then I'm going to upload this file to some server and have it served from there. The resulting code should work exactly the same on both systems.
How do I tell the system what file to use? What if my remote system is running a different (version of) the OS, and so does things slightly differently? I can't assume that the IDs of the (say) image file locally and the ID remotely will match. They could also be in different hierarchies (different roots, same relative path). They won't be executed by the same software that created them--VSC made the html file, but Apache (or whatever) will handle finding and serving the files.
Now you may say that building things like this by hand is , but it's a very common use case for text-based formats. Having to use a specific tool to do this (and thus having differences based on which specific tool you use) would be a hugely disruptive change to workflows. Cue spacebar heating issues everywhere.
-
@boomzilla said in So I decided to try to update part of my toolchain...:
@Gąska said in So I decided to try to update part of my toolchain...:
@boomzilla said in So I decided to try to update part of my toolchain...:
@Gąska said in So I decided to try to update part of my toolchain...:
@boomzilla said in So I decided to try to update part of my toolchain...:
You said that one has to query each level instead of being able to statically reference it using a path.
Not exactly. You need to query each level when traversing. When you don't know what the contents are. When you want to access file/directory you already know about, you use its ID.
So all that talk about "people never need to know about the ID" was bullshit?
You as in the program.
And you've renamed it from "path" to "hierarchical directory," which confuses your overly literal vocabulary and prevents you from seeing that from an abstract point of view they're the same thing.
Path is a sequence of fragments. When you don't have sequence of fragments, you don't have path. And this is a very important distinction, because the problems we currently have with programs doing their things on the wrong files, aren't problems with hierarchies - they're problems with paths. When you have hierarchies without paths (at least at file access API level), those problems go away even though you haven't got rid of hierarchies. This is not language pedantry, this is important issue.
Except that you're ignoring many ways in which people deal with these things and getting right back around to the same exact problem. Scripts and makefiles and config files being the most obvious here [to me].
Scripts are just ad-hoc programs - whatever you can force C++ folks into, you can force script folks as well.
We've already covered makefiles.
Yes, by doing exactly what I said.
That's not what happened.
I still don't know how config files and file paths are at all connected. Unless you're going for "you cannot put a path in config file when you don't have a path" self-defeating prophecy. Can you show a specific, high-level use case from end user's POV that would show the problem you have in mind?
Wow. I'm talking about referring to a file from within a config file. Not really different than what you'd do in a makefile.
The difference between makefiles (etc.) and config files is that for almost every human-written config file that references another file, it's possible to just slightly alter the format so that the need to reference that file goes away. Makefiles (etc.) are special because they inherently rely on the file hierarchy and textual paths to exist and there's absolutely no way around it - unlike most other config files.
You keep saying "I've covered makefiles" and I agree. It's just that you've proved me right when you did that and every time you tell me that you covered them.
Yes, you're right. But I know that if I say even one wrong word, you're instantly going to drop all other points and start acting like an obtuse retard again, and we'll have to play yet another round of "no, I really don't want to go away with filenames entirely, I never said anything like that, stop making up stuff" before we could get back on topic. "Already covered makefiles" sounds safe enough.
-
@Gąska said in So I decided to try to update part of my toolchain...:
@boomzilla said in So I decided to try to update part of my toolchain...:
@Gąska said in So I decided to try to update part of my toolchain...:
@boomzilla said in So I decided to try to update part of my toolchain...:
@Gąska said in So I decided to try to update part of my toolchain...:
@boomzilla said in So I decided to try to update part of my toolchain...:
You said that one has to query each level instead of being able to statically reference it using a path.
Not exactly. You need to query each level when traversing. When you don't know what the contents are. When you want to access file/directory you already know about, you use its ID.
So all that talk about "people never need to know about the ID" was bullshit?
You as in the program.
And you've renamed it from "path" to "hierarchical directory," which confuses your overly literal vocabulary and prevents you from seeing that from an abstract point of view they're the same thing.
Path is a sequence of fragments. When you don't have sequence of fragments, you don't have path. And this is a very important distinction, because the problems we currently have with programs doing their things on the wrong files, aren't problems with hierarchies - they're problems with paths. When you have hierarchies without paths (at least at file access API level), those problems go away even though you haven't got rid of hierarchies. This is not language pedantry, this is important issue.
Except that you're ignoring many ways in which people deal with these things and getting right back around to the same exact problem. Scripts and makefiles and config files being the most obvious here [to me].
Scripts are just ad-hoc programs - whatever you can force C++ folks into, you can force script folks as well.
We've already covered makefiles.
Yes, by doing exactly what I said.
That's not what happened.
Oh, fuck, we're back to your overly literal interpretations again. Right, you didn't use the same words, just concepts that map onto it.
I still don't know how config files and file paths are at all connected. Unless you're going for "you cannot put a path in config file when you don't have a path" self-defeating prophecy. Can you show a specific, high-level use case from end user's POV that would show the problem you have in mind?
Wow. I'm talking about referring to a file from within a config file. Not really different than what you'd do in a makefile.
The difference between makefiles (etc.) and config files is that for almost every human-written config file that references another file, it's possible to just slightly alter the format so that the need to reference that file goes away. Makefiles (etc.) are special because they inherently rely on the file hierarchy and textual paths to exist and there's absolutely no way around it - unlike most other config files.
What the fuck? What the fucking fuck? How do you remove the need to reference a file? Like, specifying certificate files for a webserver?
You keep saying "I've covered makefiles" and I agree. It's just that you've proved me right when you did that and every time you tell me that you covered them.
Yes, you're right. But I know that if I say even one wrong word, you're instantly going to drop all other points and start acting like an obtuse retard again, and we'll have to play yet another round of "no, I really don't want to go away with filenames entirely, I never said anything like that, stop making up stuff" before we could get back on topic. "Already covered makefiles" sounds safe enough.
It has nothing to do with your choice of words, even though I know you can't get out of that trap. It's that your concept recreates what we have with something more complex but without actually fixing the problems we have.
-
@boomzilla said in So I decided to try to update part of my toolchain...:
@Gąska said in So I decided to try to update part of my toolchain...:
@boomzilla said in So I decided to try to update part of my toolchain...:
@Gąska said in So I decided to try to update part of my toolchain...:
@boomzilla said in So I decided to try to update part of my toolchain...:
@Gąska said in So I decided to try to update part of my toolchain...:
@boomzilla said in So I decided to try to update part of my toolchain...:
You said that one has to query each level instead of being able to statically reference it using a path.
Not exactly. You need to query each level when traversing. When you don't know what the contents are. When you want to access file/directory you already know about, you use its ID.
So all that talk about "people never need to know about the ID" was bullshit?
You as in the program.
And you've renamed it from "path" to "hierarchical directory," which confuses your overly literal vocabulary and prevents you from seeing that from an abstract point of view they're the same thing.
Path is a sequence of fragments. When you don't have sequence of fragments, you don't have path. And this is a very important distinction, because the problems we currently have with programs doing their things on the wrong files, aren't problems with hierarchies - they're problems with paths. When you have hierarchies without paths (at least at file access API level), those problems go away even though you haven't got rid of hierarchies. This is not language pedantry, this is important issue.
Except that you're ignoring many ways in which people deal with these things and getting right back around to the same exact problem. Scripts and makefiles and config files being the most obvious here [to me].
Scripts are just ad-hoc programs - whatever you can force C++ folks into, you can force script folks as well.
We've already covered makefiles.
Yes, by doing exactly what I said.
That's not what happened.
Oh, fuck, we're back to your overly literal interpretations again.
More like we're back to you not listening to what I say. Yes, I did admit that handling hierarchies of files that reference each other that can be zipped up and sent to another computer is very hard for UID-based file access schemes and that hybrid approach might (MIGHT) be the way to go. No, I didn't say it's the only way and that it would put as back at square one with everything and we'd still have all the same problems we have now and there would be no gain whatsoever.
I still don't know how config files and file paths are at all connected. Unless you're going for "you cannot put a path in config file when you don't have a path" self-defeating prophecy. Can you show a specific, high-level use case from end user's POV that would show the problem you have in mind?
Wow. I'm talking about referring to a file from within a config file. Not really different than what you'd do in a makefile.
The difference between makefiles (etc.) and config files is that for almost every human-written config file that references another file, it's possible to just slightly alter the format so that the need to reference that file goes away. Makefiles (etc.) are special because they inherently rely on the file hierarchy and textual paths to exist and there's absolutely no way around it - unlike most other config files.
What the fuck? What the fucking fuck? How do you remove the need to reference a file? Like, specifying certificate files for a webserver?
Note that I said human-written. An ID-based ecosystem would most likely (well, almost certainly) rely much more on dedicated tooling rather than random text files everywhere. So you'd select the certificate from GUI, and the server would save its ID to config for future reference, but you as the user would never have to see this ID.
You keep saying "I've covered makefiles" and I agree. It's just that you've proved me right when you did that and every time you tell me that you covered them.
Yes, you're right. But I know that if I say even one wrong word, you're instantly going to drop all other points and start acting like an obtuse retard again, and we'll have to play yet another round of "no, I really don't want to go away with filenames entirely, I never said anything like that, stop making up stuff" before we could get back on topic. "Already covered makefiles" sounds safe enough.
It has nothing to do with your choice of words, even though I know you can't get out of that trap. It's that your concept recreates what we have with something more complex but without actually fixing the problems we have.
I have a feeling you've lost track of what problems it's even supposed to solve. So please tell me - which problems that my concept doesn't actually fix do you have in mind, exactly?
-
@Gąska said in So I decided to try to update part of my toolchain...:
I thought I made it very clear that I don't actually want to implement any of this, exactly because it'll never catch on? (
Fooled me. Good one!
-
@Gąska said in So I decided to try to update part of my toolchain...:
I have a feeling you've lost track of what problems it's even supposed to solve. So please tell me - which problems that my concept doesn't actually fix do you have in mind, exactly?
Stuff like spaces in paths being misinterpreted.
@Gąska said in So I decided to try to update part of my toolchain...:
Note that I said human-written. An ID-based ecosystem would most likely (well, almost certainly) rely much more on dedicated tooling rather than random text files everywhere. So you'd select the certificate from GUI, and the server would save its ID to config for future reference, but you as the user would never have to see this ID.
E_NUKE_FROM_ORBIT
-
@Gąska said in So I decided to try to update part of my toolchain...:
@boomzilla said in So I decided to try to update part of my toolchain...:
@Gąska said in So I decided to try to update part of my toolchain...:
@boomzilla said in So I decided to try to update part of my toolchain...:
@Gąska said in So I decided to try to update part of my toolchain...:
@boomzilla said in So I decided to try to update part of my toolchain...:
@Gąska said in So I decided to try to update part of my toolchain...:
@boomzilla said in So I decided to try to update part of my toolchain...:
In any case, the idea that modern filesystems are fundamentally broken is laughable.
The only laughable thing is your irrational fear of new ideas.
No one is afraid here. I already said that you guys were funny. That's not the same as scary. You could look it up.
Being innovative is funny. K.
Have you been to the Internet of Shit or the Dumb Things Being Crowdfunded threads?
Many times. And I've had a good laugh there. Because there was something actually wrong with those projects and I could tell you exactly what is wrong with them in one simple sentence.
Like this?
@boomzilla said in So I decided to try to update part of my toolchain...:
I'm having a lot of fun watching people recreate what's essentially identical to a normal directory structure except with incomprehensible random sequences of characters.
Like this, except I'd prefer something that's actually true.
Hmm...are you actually in @tart_savor's world?
What?
@pie_flavor didn't want his precious username in the same sentence as a bad word, so he whined until the thread title got changed.
-
@boomzilla said in So I decided to try to update part of my toolchain...:
@Gąska said in So I decided to try to update part of my toolchain...:
@HardwareGeek said in So I decided to try to update part of my toolchain...:
@Gąska said in So I decided to try to update part of my toolchain...:
There are no paths but there are still directories which can contain other directories.
How is a directory that contains another directory not a path?
Path is made by concatenating individual filenames/IDs to form a new identifier that's used to access some file. When you don't concatenate names/IDs, you don't have a path. And with system-unique IDs for all files, you don't need concatenation - you start with a directory, you query its content, and the result comes in form of file IDs that are ready to use immediately, without having to connect them with the parent ID first. So you have hierarchical directories, but don't have paths.
How do you identify this file in something like a makefile or a configuration file? How would I identify it from the command line?
There will be no command line. At least, not one that deals with paths. Because. There. Are. No. Paths.
-
@Gąska said in So I decided to try to update part of my toolchain...:
if you focused less on your hallucinations that people hate naming things and want to replace them with meaningless numbers
I think you're the one that wanted to replace paths and file descriptors with meaningless numbers, and shove that into metadata instead. Or have I also been completely misreading the last several hundred posts?
-
@Gąska said in So I decided to try to update part of my toolchain...:
You as in the program.
Greetings, program! </tron>
That's a really dick thing to clarify now, this late in the conversation.
-
@Benjamin-Hall said in So I decided to try to update part of my toolchain...:
I want to link it
I had this question upthread, seems the answer is "there will, of course, be backwards compatibility. Somehow. Probably. But I won't tell you how."
-
@Tsaukpaetra said in So I decided to try to update part of my toolchain...:
@Gąska said in So I decided to try to update part of my toolchain...:
You as in the program.
Greetings, program! </tron>
That's a really dick thing to clarify now, this late in the conversation.
I thought you like dicks?
-
@boomzilla said in So I decided to try to update part of my toolchain...:
What the fuck? What the fucking fuck? How do you remove the need to reference a file? Like, specifying certificate files for a webserver?
Well obviously you (program) need to know the file ID. And that's magic that will happen outside of config files, because the system will magically obviate needing them. Or something.
-
@boomzilla said in So I decided to try to update part of my toolchain...:
@Gąska said in So I decided to try to update part of my toolchain...:
I have a feeling you've lost track of what problems it's even supposed to solve. So please tell me - which problems that my concept doesn't actually fix do you have in mind, exactly?
Stuff like spaces in paths being misinterpreted.
Yes. And how does the problem of spaces in paths gets reintroduced in my concept?
@Gąska said in So I decided to try to update part of my toolchain...:
Note that I said human-written. An ID-based ecosystem would most likely (well, almost certainly) rely much more on dedicated tooling rather than random text files everywhere. So you'd select the certificate from GUI, and the server would save its ID to config for future reference, but you as the user would never have to see this ID.
E_NUKE_FROM_ORBIT
You know, I'm starting to think Blakey was right that you're still stuck in 1970s.
-
@Tsaukpaetra said in So I decided to try to update part of my toolchain...:
@Benjamin-Hall said in So I decided to try to update part of my toolchain...:
I want to link it
I had this question upthread, seems the answer is "there will, of course, be backwards compatibility. Somehow. Probably. But I won't tell you how."
But you'd need language compatibility going forward. You'd have to completely rewrite how HTML works (all those
href
andsrc
attributes, for example) and probably say that you can only use certain blessed tools.I taught HTML and CSS using iPads (which are similar to this issue). It was a serious pain. You had to import images into the app (thereby duplicating them on-device), you could only use files that the editor app understood (no
<video>
or<audio>
tags for you!), you could only view the resulting file from within the app (although you could zip it up and place it in something like Google Drive for uploading elsewhere), etc.This year I get to do it on laptops (still Macs, but...) and it's way better, at least for me.
-
@Gąska said in So I decided to try to update part of my toolchain...:
@Tsaukpaetra said in So I decided to try to update part of my toolchain...:
@Gąska said in So I decided to try to update part of my toolchain...:
You as in the program.
Greetings, program! </tron>
That's a really dick thing to clarify now, this late in the conversation.
I thought you like dicks?
No, I'm publicly CIS. Though I can appreciate all builds. If you googled me you'd easily find that out. My name is impossibly unique, after all...
-
@Tsaukpaetra said in So I decided to try to update part of my toolchain...:
@Gąska said in So I decided to try to update part of my toolchain...:
if you focused less on your hallucinations that people hate naming things and want to replace them with meaningless numbers
I think you're the one that wanted to replace paths and file descriptors with meaningless numbers, and shove that into metadata instead. Or have I also been completely misreading the last several hundred posts?
No, you're more or less right. But you also seem to think that filenames and paths are synonyms. Because why else would you quote me talking about filenames and reply with something about paths? No, they're not synonyms. They're very different concepts.
-
@Gąska said in So I decided to try to update part of my toolchain...:
people stopped being such assholes
Are you trying to erase @Polygeekery?
-
@HardwareGeek said in So I decided to try to update part of my toolchain...:
@Gąska said in So I decided to try to update part of my toolchain...:
people stopped being such assholes
Are you trying to erase @Polygeekery?
Don't deny my experiences bro.
-
@Tsaukpaetra said in So I decided to try to update part of my toolchain...:
@Benjamin-Hall said in So I decided to try to update part of my toolchain...:
I want to link it
I had this question upthread, seems the answer is "there will, of course, be backwards compatibility. Somehow. Probably. But I won't tell you how."
It's amazing that you could go through this entire topic and not notice even a single one out of the 50 or so times I've repeated over and over again that no, there will absolutely be no backward compatibility whatsoever.
-
@HardwareGeek said in So I decided to try to update part of my toolchain...:
@Gąska said in So I decided to try to update part of my toolchain...:
people stopped being such assholes
Are you trying to erase @Polygeekery?
I would if I could.
-
@Gąska said in So I decided to try to update part of my toolchain...:
@boomzilla said in So I decided to try to update part of my toolchain...:
@Gąska said in So I decided to try to update part of my toolchain...:
I have a feeling you've lost track of what problems it's even supposed to solve. So please tell me - which problems that my concept doesn't actually fix do you have in mind, exactly?
Stuff like spaces in paths being misinterpreted.
Yes. And how does the problem of spaces in paths gets reintroduced in my concept?
Spaces in your hierarchies. Unless you were really serious about only allowing GUI selection of files, I guess. And if you actually really still have paths in order to be able to share files with other systems but you just don't let users directly use those, I guess.
@Gąska said in So I decided to try to update part of my toolchain...:
Note that I said human-written. An ID-based ecosystem would most likely (well, almost certainly) rely much more on dedicated tooling rather than random text files everywhere. So you'd select the certificate from GUI, and the server would save its ID to config for future reference, but you as the user would never have to see this ID.
E_NUKE_FROM_ORBIT
You know, I'm starting to think Blakey was right that you're still stuck in 1970s.
You're just too enamored of
shiny
to be able to see when you're repeating history or ignoring its lessons. This is like that Joel article about rewriting software and you end up having to go through and fix a lot of the bugs that were fixed in the old code that made it so ugly in the first place and then you end up with something just as ugly because your original pristine concept was so shiny that it blinded you to all of the things that the old code had to do.
-
@Gąska said in So I decided to try to update part of my toolchain...:
there will absolutely be no backward compatibility whatsoever.
On a system you don't actually want to see implemented? Gotcha.
At this point I wonder why were even talking about this thing-we-don't-want-and-shouldn't-want-and-won't-be-made.