| View previous topic :: View next topic |
| Author |
Message |
skarnet
n00b
Joined: 01 Jul 2014
Posts: 25
Location: Paris, France
|
 Posted: Fri Sep 21, 2018 6:52 pm Post subject: |
 |
|
| Hu wrote: | | Still, I find it a bit odd to intentionally leave a file in a state that requires special close-out logic before rotation.) |
It doesn't really require special close-out logic, but when s6-log exits cleanly, it makes sure all rotations have been completed, and it fsyncs the current files. (When a file isn't being rotated, a fsync is all that's needed to "finalize" it.) Then the +x bit is set: it's a flag saying that a clean exit has been achieved.
When s6-log restarts, it checks that bit. If it's -x, it means s6-log was killed before achieving a clean exit, and so, the file may need some processing before it is ready to be appended to again:
- If s6-log was cut in the middle of writing a line, a newline must be appended, in order not to mix the incomplete line with a new one.
- If a rotation was being performed, it needs to restart at the point where it was interrupted, and logging can only happen in this logdir (and on a new current file) when the rotation has actually completed.
- Maybe other processing I'm not recalling at the moment.
Using the "finalize" terminology was probably more confusing than anything, my bad. The simple explanation is that the +x bit conveys a bit of information from one invocation of s6-log to the next one, namely "did the last invocation of s6-log exit cleanly enough for this file not to need a check-up when the next one starts?"
I hope things are clearer now. 
_________________
Laurent |
|
| Back to top |
|
 |
rain1
n00b
Joined: 13 Apr 2018
Posts: 8
|
| Posted: Sat Sep 22, 2018 9:14 pm Post subject: |
|
|
| skarnet wrote: | | what I will not accept is driving people away from experimenting with s6 with falsehoods or disingenuous FUD. |
the way you responded drove me off of working on s6-gentoo.
| skarnet wrote: | | But there's another thing that this choice is not: a security risk. And any person who pretends it's a security risk is either confused about what "a security risk" means, or ignorant of how Unix works, or ill-intentioned. |
I maintain that it is a security weakness. The +x thing isn't the main issue. The big problem is that we weren't able to discuss this, instead you insulted me.
| skarnet wrote: | | I explained this to rain1 twice on IRC, but he kept disagreeing and pretending it was a security risk. It was taking a lot of bandwidth on the channel and distracting me from other s6-related conversations with more substance and more technical grounding, so I refused to engage any further, telling rain1 to figure this out by himself and to stop wasting my time until then. I did not insult anyone; I did call rain1 disrespectful, because that's what insisting on taking space while being wrong is. |
When you said it was a waste of time I stopped talked about it. I was disappointed that you refused to hear details of the problem.
| skarnet wrote: | | I am displeased that he would speak ill of s6 to other people just because we happened to have a disagreement he was wrong about. |
It's not really about s6. This is a minor problem at worst and can be worked around. The real problem that we weren't able to communicate because of how caustic you were to me when I tried to help by raising my report. Pointing out a flaw in software isn't an attack, it's the start of a contribution to improve it.
| skarnet wrote: | | give my reassurance that any issue, especially a security issue, will be seriously investigated, as they always have been. |
You say that but in practice you were just rude to me and wouldn't listen to any elaboration about the problem, and insulted my knowledge of UNIX. |
|
| Back to top |
|
|
Akkara
Bodhisattva
Joined: 28 Mar 2006
Posts: 6702
Location: &akkara
|
| Posted: Sat Sep 22, 2018 9:32 pm Post subject: |
|
|
| skarnet wrote: | When s6-log restarts, it checks that bit. If it's -x, it means s6-log was killed before achieving a clean exit, and so, the file may need some processing before it is ready to be appended to again:
[list omitted]
[...] The simple explanation is that the +x bit conveys a bit of information from one invocation of s6-log to the next one, namely "did the last invocation of s6-log exit cleanly enough for this file not to need a check-up when the next one starts?"
I hope things are clearer now. |
Thank you for taking the time to clarify all this. I'm personally finding it interesting and may try out s6 at some point.
Returning to the +/-x vs +/-w argument for a moment, I can't help but notice that making the substitutions,also seems to achieve the goals as I understand them, with +w meaning, "in progress not finalized", and -w meaning "exited cleanly".
_________________
Many think that Dilbert is a comic. Unfortunately it is a documentary. |
|
| Back to top |
|
|
skarnet
n00b
Joined: 01 Jul 2014
Posts: 25
Location: Paris, France
|
| Posted: Sat Sep 22, 2018 10:15 pm Post subject: |
|
|
| rain1 wrote: | | I maintain that it is a security weakness. |
I think I have abundantly explained why it is not, and spent a lot of time on this already. But I'm not moderating the Gentoo forums, so if the moderators are okay with it, go ahead and explain your point of view in this thread. It's not taking away #s6 bandwidth or monopolizing my attention, so knock yourself out and be wrong on the Internet. I won't stop you.
| rain1 wrote: | | The big problem is that we weren't able to discuss this, instead you insulted me. |
Indeed, I'm not interested in discussing falsehoods. As long as you pretend the +x is a security risk, you are blatantly and factually wrong, and that's a non-starter for discussion. If you told me the Earth is flat, I would also refuse to discuss; would you consider it rude?
I said my mailbox was open if you have an exploit that would prove you right. It still is.
I did not insult you. What I did was cut you mid-bullshit. Of course you didn't like it - I wouldn't have liked it, either. But the mature reaction isn't to go to social media to complain and raise drama because you're hurt that I didn't want to listen to you. (Do you do this every time someone's not interested in what you want to say? Because, wow.) The mature reaction is to try and understand why I did not want to engage. Obviously you still don't understand that part. It's okay. I'll wait.
| rain1 wrote: | | I was disappointed that you refused to hear details of the problem. |
Yes, I refuse to talk about nonexistent problems. Want to prove there is indeed a problem? Send me a mail with the exploit.
| rain1 wrote: | | It's not really about s6. This is a minor problem at worst and can be worked around. The real problem that we weren't able to communicate because of how caustic you were to me when I tried to help by raising my report. Pointing out a flaw in software isn't an attack, it's the start of a contribution to improve it. |
Make a decision. Is it a minor problem, or a security risk? Because to me, security risks are major problems, deal breakers. So, which one is it?
If it is a minor problem, can you please stop with the "security issue" nonsense? Then we can start over and I will gladly hear your report.
| rain1 wrote: | | You say that but in practice you were just rude to me and wouldn't listen to any elaboration about the problem, and insulted my knowledge of UNIX. |
Well, I do listen to problems, and I usually want people to elaborate. Ask around; I think you'll find people generally describe me as a listening, reactive and self-demanding maintainer. Could it possibly be that there was something different about your report that made me react in such an unusual way? I wonder.
_________________
Laurent |
|
| Back to top |
|
|
skarnet
n00b
Joined: 01 Jul 2014
Posts: 25
Location: Paris, France
|
| Posted: Sat Sep 22, 2018 10:33 pm Post subject: |
|
|
| Akkara wrote: | | Returning to the +/-x vs +/-w argument for a moment, I can't help but notice that making the substitutions,also seems to achieve the goals as I understand them, with +w meaning, "in progress not finalized", and -w meaning "exited cleanly". |
It would work, except that s6-log first opens the file for writing and then checks the bits. If the file was -w, opening it for writing would fail.
I could probably refactor the whole logdir initialization sequence in order to be able to use -w instead of +x, but that would require some non-trivial work (examining recovery on failed rotations...) that I really don't want to prioritize.
_________________
Laurent |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Sun Sep 23, 2018 3:49 am Post subject: |
|
|
Silly idea: as it's an append-only log file, couldn't it use the presence of \n at EOF to mean the same as -x? i.e. new lines have one prepended to them instead (leaving an unfinished line), and closing the file cleanly appends one. A naive implementation of that would put empty line separators between successive logger runs, but that might be seen as a feature.
On second thought, that wouldn't work with log rotation commands that compress the file. Never mind, out of band is more reliable. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21607
|
| Posted: Sun Sep 23, 2018 3:48 pm Post subject: |
|
|
| skarnet wrote: | ...
I hope things are clearer now. |
Yes. Thank you for the detailed explanation. (Normally, I don't post empty thank you posts, but since you were responding to correct my misunderstanding earlier in the thread, I thought it appropriate to acknowledge that I did read and appreciate your response.) |
|
| Back to top |
|
|
Jimmy Jazz
Guru
Joined: 04 Oct 2004
Posts: 325
Location: Strasbourg
|
| Posted: Tue Sep 25, 2018 3:04 pm Post subject: is set-user-ID bit evil ? |
|
|
I'm still puzzled.
If w,x,sticky-bit won't do why not set-user-ID or set-group-ID bit ?
for instance,
| Code: |
$ chmod 4640 /tmp/log/file
me@home /tmp
$ ls -al /tmp/log
total 4
drwxr-xr-x 2 me me 60 25 sept. 15:48 .
drwxrwxrwt 11 me root 1320 25 sept. 16:20 ..
-rwSr----- 1 me me 11 25 sept. 15:54 file
me@home /tmp
$ test -u /tmp/log/file
me@home /tmp <-- errno == 0
$ /tmp/log/file
mksh: /tmp/log/file: can't execute: Permission denied
126|me@home /tmp
$ chmod 0640 /tmp/log/file
me@home /tmp
$ ls -al /tmp/log
total 4
drwxr-xr-x 2 me me 60 25 sept. 15:48 .
drwxrwxrwt 11 me root 1320 25 sept. 16:20 ..
-rw-r----- 1 me me 16 25 sept. 16:29 file
me@home /tmp
$ test -u /tmp/log/file
1|me@home /tmp <-- errno == 1
|
alternatively the effective user/group ID could be tested as well.
| Code: |
$ ls -l /tmp/log/file
-rw-r----- 1 me nobody 16 25 sept. 16:29 /tmp/log/file
me@home /tmp
$ test -G /tmp/log/file
1|me@home /tmp
$ chgrp me /tmp/log/file
me@home /tmp
$ test -G /tmp/log/file
me@home /tmp
|
_________________
« La seule condition au triomphe du mal, c'est l'inaction des gens de bien » E.Burke
| Code: |
+----+----+----+
| |::::| |
| |::::| |
+----+----+----+ |
motto: WeLCRO
WritE Less Code, Repeat Often |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
|
| Back to top |
|
|
Jimmy Jazz
Guru
Joined: 04 Oct 2004
Posts: 325
Location: Strasbourg
|
| Posted: Tue Sep 25, 2018 5:33 pm Post subject: |
|
|
Please, stop it. They are flags.
And they are posix compliant except for the sticky bit, a BSD thing since 1974. They can have no effect on executable files but still exist and can be used/set on Unix-like operating systems.
Give an example. Even Android support them even if some of them are not allowed anymore because of the nosuid mount restriction.
_________________
« La seule condition au triomphe du mal, c'est l'inaction des gens de bien » E.Burke
| Code: |
+----+----+----+
| |::::| |
| |::::| |
+----+----+----+ |
motto: WeLCRO
WritE Less Code, Repeat Often |
|
| Back to top |
|
|
skarnet
n00b
Joined: 01 Jul 2014
Posts: 25
Location: Paris, France
|
| Posted: Tue Sep 25, 2018 5:52 pm Post subject: |
|
|
Unlike the x bit, use of the suid or sgid bits would be a security issue.
_________________
Laurent |
|
| Back to top |
|
|
Jimmy Jazz
Guru
Joined: 04 Oct 2004
Posts: 325
Location: Strasbourg
|
| Posted: Tue Sep 25, 2018 10:27 pm Post subject: |
|
|
| skarnet wrote: | | ... the suid or sgid bits would be a security issue. |
I would say it is easier to set nosuid than noexec to a writable file system.
If the log file belongs to the user you will gain a user privilege or if that's still an issue you can limit the access to the group with a password (gshadow).
The suid bit has no effect on a shell script.
This settings won't make a environment insecure by itself.
_________________
« La seule condition au triomphe du mal, c'est l'inaction des gens de bien » E.Burke
| Code: |
+----+----+----+
| |::::| |
| |::::| |
+----+----+----+ |
motto: WeLCRO
WritE Less Code, Repeat Often |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21607
|
| Posted: Wed Sep 26, 2018 1:15 am Post subject: |
|
|
As skarnet explained above, setting u+x on the file should be safe since (1) it's unlikely to be a valid executable file, and (2) if it is only u+x, but not g+x nor o+x, then only the log's owner (and root) can even try to execute it.
skarnet: you say using suid or sgid would be a security issue, and in conjunction with setting an executable bit, I see the problem. What would be the problem of having the file have mode 4644 (u+s, u+rw, go+r, but all -x)? With no +x bits set, no one can execute it, so its setXid status is irrelevant, as far as I know. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed Oct 03, 2018 12:13 pm Post subject: |
|
|
| steveL wrote: | | As for stick #! whatever at the front, that's nonsense; just echo a newline to begin the file (if you don't have a standard #header), and your worries are over. (You can put whatever you want, so long as the first two bytes are not #!.) |
| Jimmy Jazz wrote: | | Not so hasty. You forget the code error returned if an error has occurred. echo a newline or # to the begin of the file returns always 0. Better see a code error as nothing. |
Eh what now?
WTF does that have to do with the initial file content?
Note that this is never a problem with a standard logging process, since the date/timestamp is always the first item in a logged message-line. (The convention being to add a space to the start of line on newline.)
So there isn't even an issue here, afaict; irrespective of saving and/or reporting error status.
| Jimmy Jazz wrote: | | BTW I still use the x flag for config files to exclude some of then in a directory :) |
Heh; I prefer the other way round, wrt conf; but never used it for anything else.
They are easy to handle though, aren't they, for an admin and/or scripter? | Code: | | for f in "$dir"/*.conf; [ -x "$f" ] || continue; sth with "$f"; done |
(Jimmy would use && continue ofc.) |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed Oct 03, 2018 12:28 pm Post subject: |
|
|
| skarnet wrote: | | Unlike the x bit, use of the suid or sgid bits would be a security issue. |
suid would only be an issue on a file marked executable; it otherwise has no meaning. So your logic only applies in the situation you have set up for yourself.
Have to say I agree with Jimmy on this, in the context of wider usage of +x, especially in root directories, from program output (not config the admin is responsible for, and knows it.)
It's for a transient state, only used by an automated process.
Not for the admin to conveniently mark a .conf as active, and more importantly, allowing a quick method to switch it off, always under admin-control (whilst making it obvious in ls.)
TBH I'm not clear why you cannot just link and unlink like ed does, but then I have no idea what is actually in play in process-terms in the program doing the rotation.
I agree that suid and +x cannot be allowed; but it does seem that suid without +x would be safer; and sgid safer still [on non-directory inodes], especially where one has dname:dname as the group. |
|
| Back to top |
|
|
CasperVector
Apprentice
Joined: 03 Apr 2012
Posts: 156
|
| Posted: Fri Oct 05, 2018 11:35 am Post subject: |
|
|
For your information, I have made slew (originally announced here), an init/rc framework based on s6/s6-rc that aims to be more friendly to distros.
The project uses rc(1) as its main scripting language; for use with Gentoo, the user is expected to install app-shells/rc and link `/bin/rc' to `/bin/rcsh'.
(As a side note, a friend of mine found execline to be very similar to the Thompson shell, which somehow also lacks expressiveness.)
New users are advised to start from the README and Manual files; please feel free to ask me if you run into problems.
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Fri Oct 05, 2018 1:57 pm Post subject: |
|
|
| CasperVector wrote: | | For your information, I have made slew (originally announced here), an init/rc framework based on s6/s6-rc that aims to be more friendly to distros. |
CasperVector ... ok, looks interesting, I shall probably give it a shot on Alpine, but I guess it's too early for packages (either for alpine or gentoo)?
One comment, quickly looking over the tree I see 'misc/wpa_supplicant/70-wpa.rc' ... please, please, use proper names, if the package/service is wpa_supplicant the rc should be called 70-wpa_supplicant.rc. With s6, daemontools, etc, there is already far too much '0foodledoodle-networks-start' or what-have-you. If slew aims to make things easier for distributions then a standard namespace, with a standard naming convention, will go some way toward making that a reality.
Thanks & best ... khay |
|
| Back to top |
|
|
CasperVector
Apprentice
Joined: 03 Apr 2012
Posts: 156
|
| Posted: Sat Oct 06, 2018 1:58 am Post subject: |
|
|
| khayyam wrote: | | CasperVector ... ok, looks interesting, I shall probably give it a shot on Alpine, but I guess it's too early for packages (either for alpine or gentoo)? |
As of now, because I use Alpine on my servers and Void on my desktop, they are the two best-tested distros for slew.
Since rc(1) is currently not packaged in Alpine, I made static-linked x86_64 and x86 binaries for it, signed using my OpenPGP key.
slew is probably too early for packaging, indeed; and although I believe it is of roughly beta quality, it is still not quite tolerant of user errors (cf. the announcement).
| khayyam wrote: | | One comment, quickly looking over the tree I see 'misc/wpa_supplicant/70-wpa.rc' ... please, please, use proper names, if the package/service is wpa_supplicant the rc should be called 70-wpa_supplicant.rc. With s6, daemontools, etc, there is already far too much '0foodledoodle-networks-start' or what-have-you. If slew aims to make things easier for distributions then a standard namespace, with a standard naming convention, will go some way toward making that a reality. |
This is quite a reasonable suggestion, and I will consider it. The current naming scheme is a result of following considerations:
* Due to the nature of supervision systems, a system package might need multiple services to work properly: eg. `wpasup.' and `wpacli.' for wpa_supplicant.
* Because of instanced services, the name of a service might become uncomfortably long (eg. `wpa_supplicant.wlan0.log'), so some kind of shortening seems desirable.
* Since the service names are already shortened, it seems also desirable to shorten filenames of the preprocessing passes, so you see eg. `70-wpa.rc'.
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sat Oct 06, 2018 9:08 am Post subject: |
|
|
| khayyam wrote: | | One comment, quickly looking over the tree I see 'misc/wpa_supplicant/70-wpa.rc' ... please, please, use proper names, if the package/service is wpa_supplicant the rc should be called 70-wpa_supplicant.rc. With s6, daemontools, etc, there is already far too much '0foodledoodle-networks-start' or what-have-you. If slew aims to make things easier for distributions then a standard namespace, with a standard naming convention, will go some way toward making that a reality. |
| CasperVector wrote: | | This is quite a reasonable suggestion, and I will consider it. |
CasperVector ... ok, good.
| CasperVector wrote: | The current naming scheme is a result of following considerations:
* Due to the nature of supervision systems, a system package might need multiple services to work properly: eg. `wpasup.' and `wpacli.' for wpa_supplicant. |
OK, but that doesn't mean those services shouldn't follow the name of the command/package/service. I know of no command/service/package called 'wpasup', or 'wpacli', those are naming conventions you've decided on, and its that I think should be avoided. I would suggest 'wpa_supplicant' and 'wpa_cli', to avoid any any ambiguity WRT the command/service being run, and to follow the naming convention provided by upstream, and the distribution packagers.
| CasperVector wrote: | | * Because of instanced services, the name of a service might become uncomfortably long (eg. `wpa_supplicant.wlan0.log'), so some kind of shortening seems desirable. |
But that is what I would expect the log to be called, so not 'wpasup.wlan0.log', or 'ws.wl0.log'. If they are "unconmfortably long" (which I don't think they are) then what is the rule for truncation? It's much better to be consistant, because if you start down the path of selecting your own names (for whatever reason) then that obviousness, or naming convention, is lost.
| CasperVector wrote: | | * Since the service names are already shortened, it seems also desirable to shorten filenames of the preprocessing passes, so you see eg. `70-wpa.rc'. |
Sorry, which service names are shortened? You mean 'wpasup' and 'wpacli'? It's those I'm arguing shouldn't be abreviated/changed, and logs should follow.
Anyhow, I'll keep you updated ... best ... khay |
|
| Back to top |
|
|
CasperVector
Apprentice
Joined: 03 Apr 2012
Posts: 156
|
| Posted: Sat Oct 06, 2018 11:16 am Post subject: |
|
|
| khayyam wrote: | | Sorry, which service names are shortened? You mean 'wpasup' and 'wpacli'? It's those I'm arguing shouldn't be abreviated/changed, and logs should follow. |
I understand the benefit of using avoiding multiple names associated with the same thing; however, the tolerance of long filenames varies from person to person.
(BTW, as you find the filenames disturbing in a sense, frankly you would probably find the names of logger users even more disturbing: cf. `base/*/prep/logdata/s6-log.rc'.)
This is highly subjective by nature, and changing the naming convention requires renaming throughout the codebase; I think a poll or so is perhaps desirable before a decision is reached.
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Tue Oct 16, 2018 8:15 pm Post subject: |
|
|
| khayyam wrote: | | Sorry, which service names are shortened? You mean 'wpasup' and 'wpacli'? It's those I'm arguing shouldn't be abreviated/changed, and logs should follow. |
| CasperVector wrote: | | I understand the benefit of using avoiding multiple names associated with the same thing; however, the tolerance of long filenames varies from person to person. |
WTF does that have to do with the price of sugar? | Quote: | (BTW, as you find the filenames disturbing in a sense, frankly you would probably find the names of logger users even more disturbing: cf. `base/*/prep/logdata/s6-log.rc'.)
This is highly subjective by nature, |
and this is meaningless rhetoric that simply uses a social argument to hand-wave a technical deficiency away (never mind the nonsense about "a poll", part of the same.)
| CasperVector wrote: | | and changing the naming convention requires renaming throughout the codebase |
Then YDIW.
(This is about admin and operator visible names or identifiers. You are a LISP-head, ffs. "Symbolic Processing" anyone?)
I mean this: you would not get away with that in #bash.
You would instead be shown how to do it right, usually with a referral to a more specific channel. (although this is basic in shell, I must point out.) |
|
| Back to top |
|
|
CasperVector
Apprentice
Joined: 03 Apr 2012
Posts: 156
|
| Posted: Wed Oct 31, 2018 2:44 pm Post subject: |
|
|
| steveL wrote: | | WTF does that have to do with the price of sugar? |
Since the natural effects of the two factors conflict with each other.
| steveL wrote: | | and this is meaningless rhetoric that simply uses a social argument to hand-wave a technical deficiency away (never mind the nonsense about "a poll", part of the same.) |
Ever heard of the programming quote, "optimise the bottleneck"?
| steveL wrote: | | Then YDIW. (This is about admin and operator visible names or identifiers. You are a LISP-head, ffs. "Symbolic Processing" anyone?) |
Yes, they DIW in the first place when shortening `list' to `ls' here and there.
And since when have I been a mindless slave of Lisp dogmatism?
("Standard-compliant" `call-with-current-continuation' anyone?)
_________________
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Thu Nov 08, 2018 5:12 pm Post subject: |
|
|
| steveL wrote: | | WTF does that have to do with the price of sugar? |
| CasperVector wrote: | | Since the natural effects of the two factors conflict with each other. |
Actually your "point" was on the tolerance of long filenames; which is why I allowed the context to remain.
IDK what the rest is about, beyond answering every point, however inanely.
User visible identifiers.. no, it's nowhere near as hard as you make it sound.
I'd say that the chances are that you are in fact caught in complexity of one's own making. (That never goes away, btw.)
But let me bow out now; too tired to chase tails. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Unsupported Software
