HN user

andrus

149 karma

http://github.com/markandrus

mark dot andrus dot roberts at gmail dot com

Posts7
Comments58
View on HN

GitHub introduced checksums to their tokens to aid offline secret scanning. AFAIK it’s mostly an optimization for that use case. But the checksums also mean you can reveal a token’s prefix and suffix to show a partially redacted token, which has its benefits.

That said, do many see value is in this?

GitHub don't host runners for Linux × arm64, so if you need this, you need to self-host. You can also run custom AMIs with pre-installed packages, which can speed up workflows that depend on those packages.

When things go wrong, you need people going through logs working out that there's nothing actually wrong with CI…

I'm on a small team who've been running the Philips Lab self-hosted runners for the past year. It hasn't been difficult to operate. Once deployed, it pretty much "just works".

In my experience, the things that go wrong originate from the GitHub workflows themselves. We usually have to review workflow logs regardless of whether the workflow uses a self-hosted runner or not.

    app : Vect n a -> Vect m a -> Vect (n + m) a
is a type signature for a function, `app`, which should append a vector (`Vect`) of length `n` to a vector of length `m`.

What's cool about Idris and other dependently-typed languages is that the length of the resulting vector, `n + m`, can be tracked in the type. This can prevent a whole slew of errors.

The theory here is good, but I think the implementation is lacking. Haskell's QuickCheck is one of the most mature frameworks for doing what the author calls "data-driven testing", so It might be worth mentioning one of the JavaScript ports compatible with Mocha: node-quickcheck, JSCheck, etc.

I think the confusion stems from the fact that .then() acts like either .map() or .flatMap() depending on the return type.

If .then() was just .flatMap(), you could expect an error if you didn't return a Promise (for example, reject with a TypeError).

If .then() was just .map(), you could return a value of any type (for example, string or Promise<number>) and get back a Promise for a value of that type (Promise<string> or Promise<Promise<number>>).

The EitherIO data type given is

  data EitherIO e a = EitherIO {
      runEitherIO :: IO (Either e a)
  }
But, for the sake of clarity, it can be written as
  data EitherIO e a = MakeEitherIO {
      runEitherIO :: IO (Either e a)
  }
The author pointed out two functions that this EitherIO declaration gave us. One is a constructor, MakeEitherIO, with type
  IO (Either e a) -> EitherIO e a
In other words, MakeEitherIO takes a value of type IO (Either e a) and returns a value of type EitherIO e a (you could think of this as "wrapping" the original IO value).

The second function, runEitherIO, is an accessor function for EitherIO's named record field "runEitherIO". It has type

  EitherIO e a -> IO (Either e a)
That is, runEitherIO takes a value of type EitherIO and returns the internal value of type IO (Either e a) (you could think of this as "unwrapping" the IO value).

I hope that helps!

No, "automatically unboxing the promises that are returned" does not give Promises "the full power of Monads", because you cannot represent a Promise for a Promise for a value. Promises/A+ breaks parametricity.

Would like to know whether the author feels his rewrite is more successful than the original. The following takes me longer to read:

    for (
                              ;
            (*to = *from) != 0;
            ++from, ++to
        )
        ;
Whereas the idiomatic version seems simpler:
    for (; (*to = *from) != 0; ++from, ++to);

Crouton is actually a breeze to use. While the crouton script itself might have a few hacks under-the-hood, the end result is quite slick. Everything just installs under `/usr/local/chroots'. Removing one of your potentially many chrooted installs is just an `rm -rf'.

I prefer keeping ChromeOS primary and just opening a crosh window to expose one of these chroots (a browser and terminal is similar to my work environment on a Mac). Granted, XFCE can act weird if you choose to launch it, but I've never needed that functionality.

If you do want to completely replace ChromeOS, there's Chrubuntu.

I'm surprised the ARM Chromebook shipped without any mechanism for indicating which apps in the Chrome Web Store are compatible with it (maybe they expected PNaCl to be completed?). Moreover, I had no idea what NaCl was until Secure Shell stalled and I tracked down the bug on a mailing list.

There's an enable "Portable Native Client" (PNaCl) in about:flags (dev. branch, at least), but I have little idea if this would fix the problem. This kind of troubleshooting is OK for power users, but seems at odds with the type of users ChromeOS wants to attract. Still love this machine, though.