emillon

I have trouble understanding the position of OpenZFS.

My understanding is that Oracle ZFS, which can not be integrated in mainline Linux, can still be distributed as a separate project (zfsonlinux.org).

On the other hand, Linux kernel developers have started btrfs, which is inspired by, but incompatible with, ZFS.

So, what is this project? I can only imagine that this is either a white room reimplementation of ZFS, or a fork before the license changed (but I think it was CDDL from the start).

A more interesting question would be: who should use or develop this? IMHO this will never be on par with "the" ZFS, so btrfs is where everyone's energy should go.

(Also, by reimplementing a ZFS product you're supporting them in a way.)

> It's a communication tool, just like email, phone and letters.

Except that it's a public company that makes money selling your data to advertisers. It's a very important difference compared to letters, phone or (to a certain extent) email.

If the old key is revoked, and is the only trust path to the new one, it's a worthless key.

If you use "git rebase -i" a lot, you should give the "autosquash" option a try. Basically, it enables "commit --fixup <commit>" that will display the commits in the correct order the next time you rebase. (A bit hard to explain, sorry)

Minor bug: the <title> says "Startup Naming".

I also advocate this "useless" use of cat, but you can write the redirection before the command:

    <"$1" pv >"$2"

I mean that the code works perfectly in the sense that the behaviour conforms to the specification, but it is hard to modify it. So, there's a problem with the code base, just one that is not visible if you don't want to extend the program (one can argue that it's the worst kind of problem).

In case people don't know, there's a built-in command to do this: \includeonly.

I don't think that there is any particular problem in the code base. Its design, however, has been made with 1970s constraints in mind.

A lot of people have thought about rewriting (parts) of TeX, but the amount of legacy is so high and you have to keep compatibility with lots of existing user code.

It's always possible to sandbox the processes. In that sense, it's not very different from the various http://try.$PROGRAMMINGLANGUAGE.org. For most of the sandboxing techniques, the performance can be however problematic.

What's peculiar about latex is that its compilation model is ridiculously inefficient. There's no separate compilation, so you have to re-run the whole compilation at the tiniest change. Also, there's a lot of I/O involved, and a several passes are needed. For example, to display the table of contents, it is necessary to append to a temporary file a list of commands (emitted by \section{} etc) which will be interpreted, in a following pass (it is necessary to manually re-run the compiler) by \tableofcontents.

You can, but it makes more sense to assign it to a void \*. After all, it's a pointer but you don't know the size of the pointed object.

Note: this is not true everywhere since (data) pointers and function pointers can be represented differently, but on a PC it works :)

You can quote the space:

    mkdir x\ y
    cd x' 'y

(or the entire part: cd 'x y')

How can a zero-day be well documented? By definition it's not yet public.

Rust already does region inference for managing borrowed pointers, so I guess that all the information needed for this is already there.

As other comments note, this is missing the point a lot. QR codes are useful (or supposed to be) because they can be scanned from a different perspective. This solution requires a particular viewing angle and cannot cope with perspective shifting, making it useless in practice.

For this particular problem, attaching a QR code to a flat surface (if possible), or using "old fashioned" 1D barcodes (they probably carry enough information) is probably a better solution.

The general problem is designing a high density, 2D barcode system that can cope with perspective shifting with a cylindrical topology ; now that would be a neat mathematical trick!

I did not answer this survey, for the following two reasons:

- there are a lot of open-ended questions. It's probably very long to fill in.

- required full name and email are a showstopper for me. Having a required email is ok of course, but why do you make it required ? And what about the full name ?

I believe that lots of people will share these concerns so I hope that it can help you tune your survey so that it's more successful.

I think that it introduces a (minor) security risk : if you have access to an idle session, and you can force a user authenticate through another means, then you can exploit the idle session to change password.

> Do you simply mean that you expected the shell to validate this, and not try to execute empty files?

I understand what happens here and why there is an error message in zsh, but I'm surprised by the fact that bash does not signal the error (exec returns -1, after all).

Bash includes logic to parse ELF[1], so I guess that after exec fails it tries to parse the file and has a special case for empty files.

    [1]: http://utcc.utoronto.ca/~cks/space/blog/unix/BashSuperintelligentExec

I find it interesting that displays the error from exec, but not bash:

    zsh: exec format error: ./a

In the standard there is a notion of "significant prefix length". ie, your symbol names may actually be truncated. In C89 the minimum guaranteed length for exported symbols was 6 (IIRC) which explains why the libc symbols are so terse. Adding underscores would greatly reduce the number of significant characters (of course, all of this is mostly obsolete these days).

Thanks!

Interesting. How modern are we talking exactly? More ext2-modern, XFS-modern or ZFS-modern?

> (Some time ago I made a table with the length of the essays vs time. I never published it, but if someone is interested I can do so.)

The answer to this kind of remark is always : please do so :)

> And of course, it wouldn't take much to make a .deb for it either.

It seems to be on its way : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706060

What is the secure alternative?

A lot of these applications could be done with a smartphone and VR. Most did not (see the failure of QR codes). I doubt that people will get dedicated hardware to perform this task.

While the maintainer does not seem very comprehensive, posting this bug report here is passive aggressive behavior at its best. What do you expect of the discussion here that could not be more productive there?

This is seriously great and very intuitive to use. Two small improvements : it would be great to be able to change brushes (at least size). The workaround is zoom/draw/unzoom which is a bit awkward. The second thing is to add an example on the landing page. I didn't take the time to try it on a picture of mine until I read the comments (and saw screenshots) here. HTH, keep up the good work!

This is not how it works. The next release name is announced approximately when the freeze starts. When a release happens, oldstable is archived, stable become the new oldstable, and the current state of testing becomes the new stable.

For a moment of time (we're talking hours), testing and stable have the same set of packages. Britney, the software which migrates packages from unstable to testing, runs four times a day. During a freeze, it is configured to need "unblock exceptions" to migrate packages. When this is option is disabled, the following britney run will make the first difference between testing and stable.

It's a classic piece that gets cited in mailing lists often these days (I actually saw it in debian-devel).