JasuM

Doesn't this mean that the broken device also answered to every ARP request? And wouldn't that break the network by itself, regardless of DHCP behavior?

Makes sense. I was thinking that maybe signal handlers could use the regular stack of the thread, but that would of course make everything fall down if the "real" code would write to the stack before updating the stack pointer.

Oh yeah, I didn't think of that. I wonder if you could write a signal handler carefully to not allocate any memory, stack or otherwise, or is some return address or an internal structure being allocated transparently...

What happens if you really run out of physical memory (including swap) after overcommitting? Does your process get a signal, or will OOM killer just run without notifying the process that triggered the condition?

My dad used a 3D printer with a Dremel attached to carve PCBs. The PCBs were those that you normally etch, i.e. they had a full copper coating.

This one's my favorite (although I haven't read the whole thing):

"This movement is designed to double the speed by gears of equal diameters and numbers of teeth—a result once generally supposed to be impossible. Six bevel-gears are employed..."

http://507movements.com/mm_226.html

I can imagine some timing-specific attacks for memory accesses, but they're not likely as robust as attacks against the branch-predictor:

1. This is the simplest one - if the memory being accessed is in a cache (L1/L2, or page in TLB), the function will take a significantly shorter time to execute. If movfuscator achieves conditional execution by manipulating index registers to perform idempotent operations, this will be very easy to detect.

2. Prefetching - if movfuscator reads memory sequentially with a detectable stride, prefetching will shorten the execution time.

3. Write combining - if the code writes to nearby addresses (same cache line), the CPU will combine them to a single write. This will cause a measurable timing difference.

EDIT: One more: Store forwarding - if the code writes to a memory address and reads it soon, the CPU may bypass the memory access (and even cache access) completely.

- Random stuff all over ~/

- User-specific bin folder ~/LocalApps (with lots of scripts)

- Projects etc. in a GoCryptFS-encrypted directory synced with Syncthing with NAS (with NFS+Kerberos on my desktop rather than Syncthing). Vendor-directories (/vendor/, /node_modules/) are not encrypted as not to slow down development, they are bind-mounted to a cleartext directory.

- PDFs, MP3s, etc. in Dropbox

I spent yesterday rewriting my ZSH config. A lot of the time I spent on figuring out how to map random key combos to unused control characters. So if I could implement both the terminal and the shell from scratch (or make a significant addition), I would implement a scenario like this:

  1. Program informs the terminal that it supports "extended keyboard input". This would be done with an escape code, much like bracketed paste.
  2. Terminal informs the program that it is now enabled.
  3. Terminal informs the program of the initial modifier key state.
  4. When the user presses a key (including modifiers), it is sent in a format that standardizes over all the commonly used key codes. Also, if the key represents a Unicode codepoint, that is sent as well. E.g. (mod-status-at-key-press)(key-code)(utf8-char-or-null)(null-terminator).
  5. When the user releases a key, a similar message would be sent.
  6. When the program exits (or a shell runs another program), it asks the terminal to disable "extended keyboard input"

Its port 26 enforces TLS though.

Requiring the same standard of verification for activating an account. Of course, they want to make it easy so it's unlikely to happen...

The point was that you could more easily replace the SSH server with a malicious one and e.g. hijack your agent when you connect to it.

I'd be very cautious before moving SSH to a non-privileged port (over 1024). Any user on the server might start their own SSH server on the port assuming the real SSH server is dead. While this is hard to exploit (needs access to normal user, needs to kill real SSH server, need to get around SSH server key checking), it still is at least a theoretical reduction in security.

That's not the server's fault, it's just Drupal being slow. It was pretty slow in version 6 and has been getting consistently slower. I'm pretty sure that the request count is for dynamic content only.

Awesome! I didn't even think that you could do that without breaking the lock apart.

Couldn't you reverse-engineer the master key from a lock anyway? Or is there some clever design preventing that?

It reads the next number in the list, it's not a random lookup. See https://github.com/id-Software/DOOM/blob/master/linuxdoom-1....

Win 8.1, Arch Linux in VMWare Workstation. I mostly use the Linux in VMWare, Windows is mostly for Excel and Photoshop.

Hardware is Lenovo Thinkpad Yoga 12".

Dev tools are vim + tmux + zsh, PHP + nginx for work and Clang + CMake for personal projects.

Besides drafting, EDH is a good format if you don't want to spend too much. When you have a 100 card deck with only unique cards (except for basic lands), people generally don't want to spend $10 on any single card.

I think it's JMP due to tail-call optimization. If there's a JMP, the RET of the inner function (bar) returns from the outer one (foo) also, and one unnecessary jump is eliminated.

If the message had some information about the Tiananmen Square massacre or some other censored information, the attack would probably stop. At least temporarily.

An interesting mechanism using differential gears, doubling the speed while only using gears of the same size:

http://507movements.com/mm_226.html

This seems to be reversible: http://www.reddit.com/r/arduino/comments/2k0i7x/watch_that_w...

I wonder if anti-virus and anti-malware companies will add this to their black lists.

I was on the list and now I got a Facebook password reset code to my phone, without asking for one. Someone already seems to be trying to use the passwords.

Recently, I set a background color for the 80th column in Vim. The gray nearest to the default bg color wasn't as subtle as I'd have liked.

Unite[0] and Vimfiler[1] for Vim. Before, searching with ag[2] required using the command line, now I can do it directly from Vim. Also, opening NERDTree took seconds, vimfiler opens in less than a second.

[0] https://github.com/Shougo/unite.vim [1] https://github.com/Shougo/vimfiler.vim [2] https://github.com/ggreer/the_silver_searcher

At least on my Mac, it opens the page for BUILTIN(1).

Boost has a very liberal license, unlike Cairo. C++ libraries, at least the GNU C++ library, have directly based some of their implementations on Boost.

This might lead to C++ library vendors not implementing the standard and requiring using a third party library, perhaps later integrating them into their own libraries.

Thinking about it, it is not probably a bad thing, it will just take longer than with other parts of the standard. Of course, this is just pure speculation and things might turn out very differently.

Cairo is dual-licensed under the LGPL and MPL. Both of these are restrictive enough to make them incompatible with, eg., App Store terms. Yet the proposal does not seem to even mention the license (or maybe I just missed it).

The standards committee is conserned about portability, at least on a technical level. I wonder what their take is on portability issues caused by license terms.