If the editor didn't make that check then read-only files contained in writable directories could be edited freely as any user, which would probably surprise people

@MichaelHomer True. But then, it's surprising that an editor could do so. I mean, all I'd need is to write a simple editor that didn't make the check and suddenly I can edit any file?

The Unix permissions model has a lot of drawbacks

The way that -w works is frequently confusing

@terdon if you can write to the directory, you can always cp readonly writable, rm readonly and mv writable readonly

You can edit any file that you could delete, which really isn't how people think but is how it works

editors which follow the “save to tmp then mv” approach have to implement additional checks themselves anyway

if they want to preserve the intent signaled by the file’s permissions

Also if they want to edit files they can't delete

There are two distinct code paths for saving a file

yes, that too

@StephenKitt true, true

basically the lack of an atomic save doesn’t combine nicely with the Unix permission model

@StephenKitt What surprises me is that this is simply at the dev's discretion. I hadn't considered this before, although it's quite obvious in retrospect in the case where a directory is writeable. I knew it was trivial to overcome, but I guess I was expecting some sort of control at the filesystem level.

Bloody hell. I've even written an answer explaining this!

And still it comes as a surprise...

In part that is the point of the sticky bit

I would like a more fine-grained permissions set to be available personally

ACLs generally still aren't good enough

@FaheemMitha well, I finally got around to benchmarking ffmpeg rebuilds. Results here ... in short, rebuilding ffmpeg made no difference. Rebuilding x264 sped it up ≈1%, which, I guess since x264 rebuilds in a minute or so, is technically worth it. Even for one encode.

(It turns out the only performance-critical parts of ffmpeg I was using, one of the deinterlacers, has an assembly version it's using. Similarly, most of x264 is assembly, too.)

Any Debian experts here who can tell if mariadb-server was available in Debian 8? (ref)

I might have answered my own question: packages.debian.org/jessie/database/mariadb-server

@JeffSchaller it was, version 10.0.25-0+deb8u1

or even 10.0.32-0+deb8u1

or 10.0.38-0+deb8u1

@StephenKitt thank you!

I'm trying to decide how much that answer was NAA

(not yours, the referenced link)

I've stopped short of deleting it, since it's apparently a viable answer, if a minimal/poor one.

I agree, I think it was an honest attempt to answer the question.

@JeffSchaller That doesn't require an expert. :-)

@derobert I'm surprised you think 1% is significant. You must be doing a lot of multimedia stuff. Wouldn't a multiprocessing approach be more fruitful?

@FaheemMitha Look at the real vs. user time :-)

ffmpeg already throws all cores at the problem

@derobert I don't follow.

user time is quite a bit higher than real (wall clock) time, because its already using a bunch of cores

That, btw, was ~8min of video. Normal thing I'd be working on is 2–4 hours.

(Also, I'm not sure I'd say 1% is significant, just that it technically is a good trade-off: an extra minute or so of compile time saves easily 5m of encode time, per video. Making a many hour encode 5m shorter, though, isn't really significant.)

@derobert Oh, I see you had a link there. Missed it.

Yeah, it would be nice if links stood out more. Though I guess Stylus or similar could fix that.

<blink><a>...</a></blink>

@StephenKitt Eww.

@derobert Not sure what your data is saying. Are you comparing new vs old?

@FaheemMitha the first one (Debian testing build) is the one I downloaded from Debian

@derobert Ah. And everything else is your build? What does march mean?

Yeah, everything else is one of my rebuilds. march is the GCC option I was trying (-march nehalem in my case)

lto is link-time optimization; the +x264 is when I rebuild x264 as well (with -march nehalem -mtune nehalem)

the -O3 was when I tacked on -O3 (instead of -O2) to the x264 build

Ok, so different compiler optimizations. Got it.

The Shakespeare build for an old hard drive would have a -march IDE

Still, the drop looks quite small to me. Are you doing multiprocessor stuff as well?

again pushing the limits for what's understandable vs goobledygook in UNIX-land

Building in parallel, I mean. That would probably be the most efficient way to speed things up. It's certainly the most obvious.

@JeffSchaller ?

@FaheemMitha it is quite small, around 1%. Build times aren't on that chart, only video encode times.

@FaheemMitha was referring to my own cryptic sentence about the Ides of March

@derobert That's what I meant, sorry. Video encode times, I mean.

I guess build isn't the right term.

build times you can probably see at gitlab.com/derobert/video-enc-container/pipelines :-)

@JeffSchaller Ah I see. Shakespeare's Julius Caesar. Right. Clever.

well, except for x264 which I just did with debuild locally

@JeffSchaller I can't think of a way to get the missing S on the end, unfortunately :-/

(it's easy enough to change x264 build flags because it uses dpkg-buildflags)

@derobert So multiprocessing for the video encode thing. Yes/No?

@FaheemMitha yes, ffmpeg already does that

@derobert Ah. Then why bothering with all the rebuilding stuff? Just get more cores (if you need them).

@FaheemMitha Well, cores cost money! But yeah, buying a new computer would definitely speed things up quite a bit more than rebuilding x264

@derobert How much money?

I thought hardware was cheap.

Well, in the US, anyway. Relatively.

Sure, nowhere near as cheap as the $0 that recompile cost, though.

@derobert Well, presumably your time has some value.

Yeah. But it was an interesting question to answer. (And having gotten ffmpeg to build is useful for other reasons, e.g., getting new versions, I think there were a few filters I've wanted to use before but they weren't in the Debian version)

@derobert Is it a more recent version, then?

And did you build a Debian package, or just the usual "from source" thing?

Just from source and plopped it in /usr/local/

@derobert Ok. Well, backporting is usually not hard, unless there are lots of Debian patches.

Unstable doesn't have a newer version. So that's a bit more work.

@derobert Yes, then it would be a bit more work.

Am I allowed to copy a header file from Linux kernel source code in my project, just to avoid installing linux-headers package?

I learnt that: tmpfs mounts are stored in the host system’s memory only, and are never written to the host system’s filesystem.

What does host system's memory mean?container using RAM of root namespace

?

@Biswapriyo sure, at least if your project's license is compatible

... though you may want to consider what happens if a new kernel version changes the header. Etc.

@overexchange It's stored in RAM (and possibly swap, I think) somewhere by the kernel.

@Biswapriyo You could, but it's not a good idea.

Install the linux-headers package.

@derobert No I will not add it, just asking. I have gpl3. But Linux is strictly gpl2 only.