jewbacca's comments

jewbacca | 7 years ago | on: Ecuador will hand over Julian Assange to the UK

I've always considered this bit of writing from 2006 to be Assange's (and Wikileaks') central thesis:

----

"The non linear effects of leaks on unjust systems of governance

[...]

The more secretive or unjust an organization is, the more leaks induce fear and paranoia in its leadership and planning coterie. This must result in minimization of efficient internal communications mechanisms (an increase in cognitive "secrecy tax") and consequent system-wide cognitive decline resulting in decreased ability to hold onto power as the environment demands adaption."

https://web.archive.org/web/20071020051936id_/http://iq.org:...

https://cryptome.org/0002/ja-conspiracies.pdf

----

I still believe that this will bear out in the long-run, and has already begun to bear out in smaller-scale cases, but it is becoming apparent that in many cases this is like a "the market can stay irrational longer than you can stay solvent" situation, and has really barely begun.

As for Assange personally, I still kinda believe in him, though I recognize that is on shakier ground than it may once have been. After 8 uninterrupted years of however an honest and empathetic person might describe his conditions, I would not be surprised, nor would I particularly fault him for losing it a bit, and letting his personal situation (... being fucking personally targeted for destruction by an unfathomably powerful global-scale system of secretive injustice) compromise his personal pretence towards the objective neutrality on which his thesis's large-scale fruition is predicated.

jewbacca | 7 years ago | on: Lambdas and Functions in Python

Someone replied with and then unfortunately deleted an extremely good suggestion.

Instead of each operation taking a variable number of numbers and then either returning a value or directly changing the state of the stack (which was also a bug in my previous gist, in pushing the result of C and AC): homogenize the types of the operations by making all of them take a stack and return a stack.

You could also wrap all of the basic arithmetic functions with a higher-level function so that, eg, `add` would still not actually have to be aware of the stack:

    import math, operator

    def stackFunction(arity, function):
        return lambda stack: stack[:-arity] + [function(*stack[-arity:])]

    class rpn_engine:
        def __init__(self):
            self.stack = []
            self.catalog = {"+":    stackFunction(2, operator.add),
                            "-":    stackFunction(2, operator.sub),
                            "*":    stackFunction(2, operator.mul),
                            "/":    stackFunction(2, operator.truediv),
                            "^2":   stackFunction(1, lambda x: x * x),
                            "SQRT": stackFunction(1, math.sqrt),
                            "C":    lambda stack: stack[:-1],
                            "AC":   lambda stack: []}

        def compute(self, operation):
            self.stack = self.catalog[operation](self.stack)

        def push(self, number):
            self.stack.append(number)

jewbacca | 7 years ago | on: Lambdas and Functions in Python

Most of the code by volume in this post's final product (and most of the ugliness you're probably seeing in it) comes from dealing separately with the arity of different operations (`compute_operation_with_one_operand`, `compute_operation_with_two_operands`, etc) -- which retains a whole lot of copy-paste-but-change-one-small-thing-in-the-middle boilerplate.

That can be taken further and generalized out.

It's been a while since I did much Python metaprogramming-navel-gazing, but if you can't do something to automatically detect the arity of the operations' lambdas/functions, you can at least explicitly annotate the operations data with their arity -- which is already implicitly being done (as code instead of data) in `compute`'s 3 if-statements + the 3 "compute_with_N_operands" functions.

From there, you'll only have 1 case once, instead of 3 cases with each one manifesting in 2 different places. And just about half of the code disappears.

----

edit: since adjkant already covered the "automatically detect the arity of the operations' lambdas/functions" approach to removing all the cases, (https://news.ycombinator.com/item?id=17329772), here is the gist of what I meant by "explicitly annotate the operations data with their arity":

    import math, operator

    class rpn_engine:
        def __init__(self):
            self.stack = []
            self.catalog = {"+":    (2, operator.add),
                            "-":    (2, operator.sub),
                            "*":    (2, operator.mul),
                            "/":    (2, operator.truediv),
                            "^2":   (1, lambda x: x * x),
                            "SQRT": (1, math.sqrt),
                            "C":    (0, self.stack.pop),
                            "AC":   (0, self.stack.clear)}

        def compute(self, operation):
            (arity, op) = self.catalog[operation]
            operands = reversed([self.stack.pop() for _ in range(arity)])
            return self.stack.push(op(*operands))

jewbacca | 8 years ago | on: Show HN: Password-protect a static HTML page

You don't need to control the server

But you can still control access to the content, distributing the password by other channels.

A plausible use case for this (... like basically any crypto thing) would be clandestine organizing. Significantly less sophistication required, and much less of a trail left, to put a static site online.

Shit, you wouldn't even need to host it as a site: you could drop it somewhere as text, eg on a pastebin or in a forum comment, with "save as .html and open" instructions. And you could distribute the encryptor itself the same way.

The really great thing about this is that you could do practical human crypto, without Alice or Bob needing any special knowledge or equipment besides a web browser, using arbitrary uncontrolled public infrastructure.

... though if someone knows the password + controls the infrastructure you've used, they could substitute their own content.

... also short password + direct access to ciphertext -> easy brute force.

... also everything here: https://news.ycombinator.com/item?id=14554187

Wouldn't use it for anything state-level or life-or death. There are mitigations, but that would increase the difficulty and necessary sophistication for using it. Actually, this probably falls into the uncanny valley where it seems just accessibly cyberpunk enough to be extremely dangerous to anyone relying on it. But still, really cool IMO.

jewbacca | 8 years ago | on: Ask HN: What are we doing about Facebook, Google, and the closed internet?

Yeah. This was pretty upsetting to discover. I had been blindly using my reddit upvote history as a supplementary personal log of sorts, for many years. And most of that's now just gone.

Thank god I haven't made over 1000 comments or posts with any one account.

The data's all still in the database, but due to their caching setup, only the last 1000 of anything is publicly indexed. While everything's technically reachable, it's all deep web. To recover something private like upvoted or saved posts, we're talking heat-death-of-the-universe, through a full-table-scan squeezed through brute-forcing a search box, while authenticated, with rate limits.

jewbacca | 8 years ago | on: Did the Intercept bungle the NSA leak?

That was exactly Julian Assange's original thesis:

----

"The non linear effects of leaks on unjust systems of governance

[...]

The more secretive or unjust an organization is, the more leaks induce fear and paranoia in its leadership and planning coterie. This must result in minimization of efficient internal communications mechanisms (an increase in cognitive "secrecy tax") and consequent system-wide cognitive decline resulting in decreased ability to hold onto power as the environment demands adaption."

https://web.archive.org/web/20071020051936id_/http://iq.org:...

https://cryptome.org/0002/ja-conspiracies.pdf

jewbacca | 8 years ago | on: Just Say No

Sorry: there is not an will never be a general answer to that question.

jewbacca | 9 years ago | on: Long-Term Thinking and Nuclear Waste

> nudging the dry casks sunward

[Note: I realize you might already get this. But for the sake of having the discussion in public, where this is a very common misunderstanding of space travel, and also because I enjoyed writing it:]

It's true that, in space, without air resistance, Newton's first law reaches its fullest expression: when you push something, it's going to keep going.

In a frame of reference with no gravity happening in it -- like a totally empty universe, or if you're restricting the area you're looking at to the interior or immediate vicinity of a space ship over a short period of time -- then it's going to keep going in a straight line. ie: if you give something a push in what looks like the direction of something else, it'll get there. And it wouldn't matter how hard the push was, it would still get there eventually.

But if you're working in frame of reference with a lot of gravity happening in it, straight lines stop being the usual mode of movement. If you start at rest and push straight towards something, you're going to curve away from your apparent initial trajectory, towards the source of the gravity. You can't just gently push directly towards something and eventually end up there.

"Well", you say, "we can still just push directly towards the source of the gravity -- which is our destination anyway." Absolutely! We'd successfully end up there, and it would even still be a straight line. If we were starting at rest.

But we're not starting at rest: we're starting out with a velocity of about 100,000 km/h, in a direction perpendicular to a straight line towards the sun. The velocity of the orbit of the earth around the sun.

Starting from there, if we were to give a really big push, directly towards the sun, say a ~15,000 km/h push (the magnitude of the push that moved the Apollo missions from low-earth orbit onto a collision-course with the moon)... that would just leave us in a slightly off-center orbit, which only gets very slightly closer to the sun at its closest point. And actually moving just a little faster than we were (~101,000 kh/h), at an angle less than 10 degrees closer to "towards the sun" than our previous direction of travel.

Think hypotenuse of a triangle. Pythagorean theorem and stuff. Really big width (our initial orbital velocity around the sun), relatively small height (our big push towards the sun). If we want our hypoteneuse (our actual velocity vector) to get really steep (point directly towards the sun), and changing the height of the triangle is our only move (again, pushing towards the sun), we'd basically need our triangle to achieve infinite height (infinitely big push towards the sun).

We could actually do significantly better by making our push in the direction opposite to our initial orbit, rather than directly inwards towards the sun. With a push of the same magnitude, now we're orbiting at only 85,000 km/h, making our orbit dip lower at its closest point.

In fact, that reveals what we actually need to do to dump something into the sun: stop orbiting it.

Cancel (almost) all of our initial 100,000 km/h of orbital velocity. By accelerating 100,000 km/h in the opposite direction to our orbit. When that's done, we fall into the Sun.

----

No extensive comment on the logistics of this. Your [2] link discusses that more fully.

My point is that "nudge something in the right direction in space, and it'll get there eventually" is not actually a thing that can happen in any practical sense.

tldr: play Kerbal Space Program.

jewbacca | 9 years ago | on: EFF Border Search Pocket Guide

The upside-down part:

----

Before your trip:

Reduce the data you carry. Consider using temporary devices, deleting data from your regular devices, or shifting data to the cloud.

Encrypt. Use strong full-disk encryption, not just weak screen-lock passwords.

Passwords. Use software to make them long, unpredictable, and memorable.

Backup. In case agents seize your devices, backup your data.

Power down. Do it before arriving at the border, to block high-tech attacks.

Fingerprint locks. They are weaker than passwords, so don’t rely on them.

Apps and browsers. Agents use them to get from devices to cloud content. Consider logging out, removing saved login credentials, and uninstalling.

But be aware: Unusual precautions may make border agents suspicious.

At the border:

What if border agents instruct you to unlock your devices, provide your passwords, or disclose your social media information? There is no “right” answer.

Be safe. Stay calm and respectful. Do not lie to agents, which can be a crime.

If you comply, agents may scrutinize and copy your sensitive data.

If you refuse, agents may seize your devices. They also may escalate the encoun-ter, for example, by detaining you for more time.

If you are a U.S. citizen, agents must let you enter the country.

If you are a lawful permanent resident, agents might raise complicated questions about your continued status as a resident.

If you are a foreign visitor, agents might deny you entry

jewbacca | 9 years ago | on: Run Linux on hard disk firmware (2013)

> jellybean part

...

> In the electronics industry, a "jelly bean" component is one which is widely available, used generically in many applications, and has no very unusual characteristics—as though it might be grabbed out of a jar in handfuls when needed, like jelly beans. For example, the μA741 might be considered a jelly bean op amp.

[Wikipedia]

jewbacca | 9 years ago | on: Programs that have saved me 100+ hours

This is a relatively fresh reinstall, and I've only been adding gestures as they come up [0] -- so this should be pretty representative of my top usage (slightly reordered for organization):

https://i.imgur.com/qvAOmHA.png

----

I think I can say with a fair amount of confidence that 3 Finger Tap (open in new tab), Pinch In/Out (close/open tab), and Rotate Left/Right (change tab) are my most used custom gestures.

With 3 Finger Swipe Left/Right (back/forward) configurable in vanilla system preferences, but done in BTT for consistency, and 4 Finger Swipe Up (Show Desktop)/Down (Mission Control) with their directions reversed from the system defaults [1].

Really, every one of the gestures on there is pretty indispensable to me feeling comfortable using a computer. Going back to keyboard shortcuts for the same actions (eg, when I'm using someone else's computer) feels like hunting-and-clicking menu items with a mouse.

----

[0] Import/Export is a thing, but I usually use a reinstall as an opportunity to tighten things up.

[1] Because this way makes way more intuitive sense to me. Swipe Up = Swipe Away = "GTFO windows". What hell, Apple HCI engineers?

gadtfly | 9 years ago | on: Programs that have saved me 100+ hours

BetterTouchTool (https://www.boastr.net/) is kinda like an AutoHotKey for OS X -- but on top of custom keyboard shortcuts, it also allows you to configure custom trackpad gestures.

It's easily saved me 100+ hours -- a half-second at a time, 400 times a day. And probably a couple cases of RSI, a couple inches of finger contortion at a time.

The economy of motion is as far beyond keyboard shortcuts as keyboard shortcuts are beyond hunting around with a mouse. It's crime more people don't use it.

jewbacca | 9 years ago | on: Flexbox Cheatsheet

Yes, it is my understanding that one of the major, inviolable design goals in this is not to break any old behaviour, or any such (yes, totally distasteful) "hacks" dependent on it. Now that particular old behaviour is "isolated" under the `display-inside: flow` formatting context, which has to remain the default.

Lets go back to the spec draft:

----

https://drafts.csswg.org/css-display/#propdef-display

> The display property defines box’s display type, which consists of the two basic qualities of how an element generates boxes:

> * the inner display type, which defines [...] the kind of formatting context it generates, dictating how its descendant boxes are laid out.

> * the outer display type, which dictates how the box participates in its parent formatting context.

...

> <display-inside> = flow | flow-root | table | flex ...

> <display-outside> = block | inline | ...

----

It's not just the reframing into `display-inside` (how to lay out children) and `display-outside` (how to participate in parent) which addresses your problem -- that just provides a new way to specify the same behaviour as before. Split into 2 orthogonal axes, cleanly leaving room for new behaviour to exist in combination with old behaviour.

But, rather, it's that plus the specific provision of `display-inside: flex`, within this new framing, which addresses your problem.

If you stick with `display-inside: flow` in your examples of things that are problems, of course nothing is going to change, because that specifically specifies "behave like you always used to".

I'm honestly not sure I understand your complaint. I'm definitely open to the possibility that this is an internally-inconsistent or short-sighted solution, but I'm not seeing it here.

jewbacca | 9 years ago | on: Flexbox Cheatsheet

As far as I can tell, the only way the source-whitespace will appear is when both of the following are true:

1. The parent has `display-inside: flow` or `display-inside: flow-root` (ie, the "original", pre-flexbox, formatting contexts)

  eg `display: block`, `display: inline`, `display: inside-block`
2. The children have `display-outside: inline`

  eg, `display: inline`, `display: inline-block`, `display: inline-flex`
In any other combination, the source-whitespace disappears, in some way or other.

----

What I think you want, a horizontal row disregarding source-whitespace, could be achieved with `display-inside: flex` (eg, `display: flex`, `display: inline-flex`) on the parent (with `flex-direction: row` being the default). So:

    img-row {
        display: flex;
    }
aka

    img-row {
        display: block flex;
    }
aka (though this syntax has been temporarily removed)

    img-row {
        display-outside: block;
        display-inside: flex;
    }
aka

    img-row {
        display-outside: block;
        display-inside: flex;
        flex-direction: row; /* the default */
    }
----

Note that this longhand syntax doesn't seem to be implemented in Chrome, at least, yet. So if you want to check it out, you'll have to work in the shorthand (still translatable from the longhand as specified in the draft spec https://drafts.csswg.org/css-display/#propdef-display).

jewbacca | 9 years ago | on: Flexbox Cheatsheet

In this formulation, `block` is a <display-outside> value, and would not be valid as a <display-inside> value.

----

<display-inside>, which can be `flow`, `flex`, `grid`, etc, but not `block`:

> defines [...] the kind of formatting context it generates, dictating how its descendant boxes are laid out"

https://drafts.csswg.org/css-display/#formatting-context

Which, as I interpret it, is "just" another level of indirection on top of your proposal, providing a mechanism for more messy and incompatible, legacy and future, layout systems to coexist.

jewbacca | 9 years ago | on: Flexbox Cheatsheet

In anything implementing the current draft of CSS Display Module Level 3, the `display` values we commonly use today become a shorthand for two orthogonal properties.

For example, `display: block` becomes shorthand for `display: block flow`, where `block` is the <display-outside> and `flow` is the <display-inside>.

----

https://drafts.csswg.org/css-display/#propdef-display

> The `display` property defines box’s display type, which consists of the two basic qualities of how an element generates boxes:

> * the inner display type, which defines [...] the kind of formatting context it generates, dictating how its descendant boxes are laid out.

> * the outer display type, which dictates how the box participates in its parent formatting context.

...

> <display-outside> = block | inline | ...

> <display-inside> = flow | flow-root | table | flex ...

...

   Short `display` | Full `display`     | Generated box
   ----------------|--------------------|---------------
   'block'         | 'block flow'       | block-level block container
   'flow-root'     | 'block flow-root'  | block-level block container that establishes a new block formatting context
   'inline'        | 'inline flow'      | inline box
   'inline-block'  | 'inline flow-root' | inline-level block container
   ----------------|--------------------|---------------
   'flex'          | 'block flex'       | block-level flex container
   'inline-flex'   | 'inline flex'      | inline-level flex container
----

----

It looks like there were, in the first draft of the spec, independent `display-inside/outside` properties, with `display` being a "one property that sets multiple properties" shorthand:

https://www.w3.org/TR/2014/WD-css-display-3-20140911/#the-di...

But that has since been changed to `display` being a "one property that takes multiple values" shorthand, in the current version of the spec:

https://www.w3.org/TR/2015/WD-css-display-3-20150721/#change...

> Changes since the 11 September 2014 Working Draft include:

> Removed `display-inside`, `display-outside`, and `display-extras` longhands, in favor of just making `display` multi-value. (This was done to impose constraints on what can be combined. Future levels of this specification may relax some or all of those restrictions if they become unnecessary or unwanted.)

page 1