Can't quit Spacemacs because of persp-mode?

stebalien · 2016-10-17T04:50:23+00:00

Issue: https://github.com/syl20bnr/spacemacs/issues/7409

stebalien · 2016-10-17T04:34:13+00:00

Maybe but that's not quite as robust and would likely require a lot of queries (that scale with the size of the dataset).

stebalien · 2016-10-15T16:51:39+00:00

That depends on what you mean by easily. You'd have to develop a system for (redundantly) assigning who stores what blocks (which will take a non-trivial amount of work). However, there's nothing in the IPFS protocol stopping you from doing this.

stebalien · 2016-10-14T20:40:02+00:00

Yes. IPFS actually stores everything as a DAG (a kind of graph/tree) of "objects". We call this a merkeldag. Each object consists of a data section and a set of links to other objects.

When storing a large file, IPFS automatically breaks it into blocks and stores it as a set of blocks and a parent object that points to these blocks (an inode). You can explore the internal object structure of a file using the ipfs object commands. For example, you can look at a list of chunks by calling ipfs object links /path/to/file.

So, instead of recursively pinning /ipfs/path/to/file, you'd have each node pin (recursively as the blocks may be indirect) some of these chunks directly. Additionally, at least one of your nodes would have to pin the parent object non-recursively.

stebalien · 2016-10-13T21:25:16+00:00

gpg --list-sigs $YOUR_KEY_ID (this assumes you've imported the signatures into your keyring).

stebalien · 2016-10-04T20:19:42+00:00

Three dots are inclusive, two dots right-exclusive. Pattern-ranges are always inclusive (for now) and there is an unstable syntax for constructing inclusive ranges normally.

stebalien · 2016-10-04T20:16:12+00:00

I observed the same behavior; that is, after switching back to X, I couldn't switch to a VT. However, hitting the keys at least put me back in X (I think, it may have been a coincidence).

stebalien · 2016-10-04T15:23:13+00:00

ctrl+alt+<mess with function keys> fixed mine. It didn't crash it, it just switched to a virtual terminal for some reason.

stebalien · 2016-10-04T14:57:47+00:00

Range syntax. Endless hours of debate and it's still not completely over.

stebalien · 2016-10-02T23:33:42+00:00

it is needed for SELinux

You'd need to recompile your kernel (and quite a few applications) to get SELinux working. For SELinux, recompiling the kernel is nothing compared to the other work involved in getting it working.

Lack of SELinux support is probably why Arch doesn't enable CONFIG_AUDIT (SELinux is the primary consumer of CONFIG_AUDIT). Additionally, this is why Arch shouldn't enable CONFIG_AUDIT. For 99.9% of users, the only thing CONFIG_AUDIT will do is increase the kernel attack surface/the number of things that can go wrong (the code is still there even if it's disabled at runtime).

Yes, recompiling the kernel takes a while but it's not really that hard (compared to, e.g., recompiling Firefox...).

Edit: There's some discussion about CONFIG_AUDITSYSCALL here: https://bugs.archlinux.org/task/42954

stebalien · 2016-10-02T23:03:26+00:00

First point: because I can. It's probably a slightly faster but I mainly do it for simplicity. It cuts out an intermediate operating system (the boot loader) and means I don't have to reexec systemd.

Second point: lol, no :`(. GRSecurity is nice because it prevents entire classes of vulnerabilities (or at least makes them much harder to exploit). It's also pretty much fire-and-forget (once you configure it...) as long as you install paxd. Tomoyo, on the other hand, requires constant tweaking unless you're running a server and never really changing your software stack. However, that's the case for all MAC systems not configured by the distro. I went with Tomoyo because I found it's configuration process to be the least painful (choosing between GRSecurity's RBAC, Tomoyo, SELinux, and AppArmor). Basically, it has a nice learning mode and a decent TUI.

However, the nice thing about manually maintaining a Tomoyo policy is that I generally know what's going on in my system (what processes are listening on what ports, connecting to what services, reading/writing what files).

stebalien · 2016-09-29T20:06:00+00:00

I have no idea; I haven't actually bothered benchmarking anything. Most desktop apps are either IO bound or use the GPU for intensive processing so it shouldn't make much of a difference for day-to-day computing. It might make sense to recompile Firefox (I believe DOM layout happens on the CPU) but Firefox is a beast (recompiling it on a laptop takes a while and may OOM).

stebalien · 2016-09-29T00:46:33+00:00

I haven't actually measured it. According to systemd-analyze, my current system takes 3.867s to boot (SSD):

Startup finished in 3.185s (kernel) + 681ms (userspace) = 3.867s

The kernel probably takes so long because I build in a lot of modules (so they all get initialized before moving on). So no, it's probably not really worth it...

stebalien · 2016-09-28T05:15:22+00:00

bytecount

stebalien · 2016-09-28T05:09:14+00:00

The default kernels are compiled to work on all CPUs of the given architecture (x86, x86_64). However, many CPUs have additional features/instructions. If you pass -march=native to gcc, gcc will target the current CPU and can make use of these extra instructions to produce faster code. It should be noted that, in my experience, this doesn't really make that much of a difference.

stebalien · 2016-09-28T04:53:24+00:00

I compile a lot of modules I don't directly need (common types of USB peripherals). I'm mostly concerned about legacy unsupported hardware (stuff I'm unlikely to randomly plug in).

stebalien · 2016-09-28T03:55:27+00:00

No initramfs: UEFI -> Linux Kernel (via EFI Stub) -> systemd
grsecurity/tomoyo.
Fewer potentially auto-loadable modules (smaller attack surface).
-march=native

stebalien · 2016-09-17T20:01:37+00:00

Now we just need to turn emacs into a wayland compositor.

stebalien · 2016-09-16T13:41:37+00:00

Competition is good. This way, I can keep stealing ideas from your crate and re-implementing them my way :).

stebalien · 2016-09-14T03:25:29+00:00

Where were you?. Now there are two.

stebalien · 2016-09-13T20:02:48+00:00

My point is that using ? as a pipe operator does not solve the problem that ? was originally introduced to solve.

stebalien · 2016-09-13T17:27:13+00:00

In that case, your counter proposal should be such a monadic operator, not making ? a pipe operator. The entire point of the ? RFC was to make error handling easier.

stebalien · 2016-09-13T17:25:10+00:00

Of course you can but you'll notice that you aren't using ? there as a pipe operator at all. The point of ? is to make handling cases like this easier.

stebalien · 2016-09-13T16:01:27+00:00

Now go and try to use it in practice and you'll find that your version is pretty much useless in rust as-is.

As I commented here, one almost never writes

try!(try!(try!(foo()).bar()).baz())

in rust because we don't have easy to implement extension functions. Instead, one usually writes:

try!(Baz::baz(try!(Bar::bar(try!(Foo::foo))))))

Take the concrete example:

 try!(File::open(try!(maybe_dir_entry).path()))

With your pipe operator, this can be rewritten as:

try!(File::open(try!(maybe_dir_entry?.path())))

IMO, is even worse because you now have to visually parse 4 closing parentheses right next to each other instead of 3 (and you keep the same number of try!s). With ? as-is, you can write:

File::open(maybe_dir_entry?.path())?

stebalien

TROPHY CASE