How not to sign a JSON object - <AUTHOR> https://latacora.micro.blog/2019/07/24/how-not-to.html <comment><USER2> An easy enough mantra: sign bytes, not semantics. I've trudged through the bowels of SAML long enough to know that canonicalization is thoroughly tricky and annoying to deal with.

I don't care what you throw in the bytes; I can figure that out easily enough. I want to know who generated those bytes and that they haven't changed.

For this reason also, I think the "reach for symmetric first" is bad advice. The primary benefit I can think of for HMAC is if you want to store client- side state for more stateless browser-targeted services. It makes it easy to throw an obscure cookie to your client and then validate it on the way back. It seriously complicates things if you want to allow other people to validate provenance of those bytes. With symmetric crypto, as soon as you can validate you can also generate. That's not the system we want.

<comment><USER3> You say that's not the system you want but that's based on a pretty big "if": you need "someone else" to validate something, and those people can't talk to you directly and ask you if it's valid or not. That's not in practice how we see this being used.

If you do need third parties to validate, a much simpler API is to just ask the thing that holds the HMAC credential over TLS, and have it return true/false. That makes it harder to demonstrate non-repudiation, but I'm not convinced that's a property you generally care about. Even in OIDC (which mandates a JWT, but for reasons that defy understanding doesn't mandate cryptographic domain separation between (IdP, RP) pairs), leading OIDC providers have long recommended you just talk to them over TLS to get userinfo. (GSuite has recently muddled this in their docs, which irks me.)

(Disclaimer: I'm the author.)

<comment><USER4> > holds the HMAC credential over TLS, and have it return true/false

And if you're connecting to the original party anyway might as well not even use HMAC or any crypto at all. When "signed" data needs to be sent to the client don't send it at all, instead store the data locally under a GUID and send that GUID to the client. When client takes their GUID to another party, that other party connects to the original party and retrieves perfectly authentic data. Free bonus - faster client performance.

Best crypto is absence of crypto.

<comment><USER5> This multi step interaction has some spectacular failure scenarios.

<comment><USER4> > spectacular failure scenarios

Such as? Any of them different than that of the suggestion I was replying to?

</comment></comment></comment></comment></comment><comment><USER6> I recall this plaguing the Secure Scuttlebutt project -- they were signing JSON objects that were encoded however Node saw fit to encode them, which meant that in order to write an alternative implementation of the protocol, you had to encode all the various objects _exactly_ how Node encodes them, which is (unsurprisingly) non-trivial. I wonder if they addressed this in a later version.

<comment><USER7> If you're serializing the JSON, that is UTF8. You're signing UTF8 bytes... don't mess with them, and the signature will be the same... also, for JWT, the UTF8 is then converted to base64 representation and tethered to the signature. You're signing the UTF8 bytes, not JSON. It doesn't matter how it's serialized, if it isn't UTF8, you're doing it wrong. The order or properties doesn't matter, the signature is on the bytes.

<comment><USER8> SSB signs objects like so:

        {
          "previous": "%XphMUkWQtomKjXQvFGfsGYpt69sgEY7Y4Vou9cEuJho=.sha256",
          "author": "@FCX/tsDLpubCPKKfIrw4gc+SQkHcaD17s7GI6i/ziWY=.ed25519",
          "sequence": 2,
          "timestamp": 1514517078157,
          "hash": "sha256",
          "content": {
            "type": "post",
            "text": "Second post!"
          }
        }

gets signed like

        {
          "previous": "%XphMUkWQtomKjXQvFGfsGYpt69sgEY7Y4Vou9cEuJho=.sha256",
          "author": "@FCX/tsDLpubCPKKfIrw4gc+SQkHcaD17s7GI6i/ziWY=.ed25519",
          "sequence": 2,
          "timestamp": 1514517078157,
          "hash": "sha256",
          "content": {
            "type": "post",
            "text": "Second post!"
          },
          "signature": "z7W1ERg9UYZjNfE72ZwEuJF79khG+eOHWFp6iF+KLuSrw8Lqa6
                        IousK4cCn9T5qFa8E14GVek4cAMmMbjqDnAg==.sig.ed25519"
        }

which means that you have to be careful about how you remove the signature in order to verify the original. The "main" node implementation does this by parsing the json, removing the field, and then re serializing, forcing any alternate implementation to exactly match the node serialization in order to be compatible

<comment><USER9> I'd be really curious as to why they chose not to go with something like

        {
          "data": {...}
          "signature": "z7W1ER..."
        }

<comment><USER8> as far as I can tell, it's cause they are hardcore JS devs, where JSON is seen as almost a part of the language, and little to no effort was put into things like future-proofing. A lot of the failings have been fixed as the community grows, but this one is core to how the whole thing works, so changing it at this point is fairly non-trivial (would basically involve completely breaking any kind of backwards compat, and potentially even some forwards compat)

</comment></comment></comment></comment></comment><comment><USER10> I'm sort of skeptical of the idea that a bunch of people hand-rolling HMAC stuff is going to contain fewer security issues in the long term than widely- used, tested JWT libraries. Sure if they do exactly what you say here, and nothing else, that might work. But what happens when they realize they need some minor tweak to it…

<comment><USER7> Beyond that, hand-rolling JWT isn't so hard at all. When I read about some of the exploits in certain libraries, I didn't have to worry about it, as I only supported the known authority's public key in the system I was working on.

Of course, that makes the header effectively useless in practice.

<comment><USER11> There are two obvious problems with this approach to engineering:

1\. You don't know what you don't know, and there is _a lot_ to know about cryptography beyond the minimum needed to interoperate with other systems.

2\. If you're engineering seriously, you know people are going to inherit your code and your design down the road, and if you're relying solely on a minimal feature set without a coherent, informed design, those people are building on sand.

Rolling your own JWT is a bad plan.

<comment><USER12> It's not like he is rolling out his own crypto library. He's just rolling his own token but encrypted/signed with industry standard crypto.

It's not terrible to "roll your own JWT" if you don't actually care about interoperability. And he's right, it does sidestep a lot of issues because JWT and corresponding libraries are designed to handle far more use-cases than what he may need it for and therefore if you don't fully understand it all, you may be shipping with unsecure configuration.

</comment></comment></comment></comment><comment><USER13> A fun read and primer on the subject. However, I would like to see more emphasis on including a time stamp as part of the signed payload. The reason is multifold: (a) Most importantly prevents 'replay attacks' [1]. Systems that need to send send the same command will do so with a unique time stamp and, therefore, a unique signature. (b) The time stamp + signature is an idempotency key. Your key cache's TTL is the same as the timeout for your time stamp rejections. (c) To a lesser extent bolsters the system against a brute force length extension attack (see the Flickr API flaw in the reading) by reducing the time the middle-man has to correctly calculate the glue bytes.

1: [https://en.wikipedia.org/wiki/Replay_attack](https://en.wikipedia.org/wiki/Replay_attack)

</comment><comment><USER14> It's amazing to me that the whole article glosses over issues around key storage for symmetrical encryption, not to mention now you have an O(n) liability issue with all of your readers.

<comment><USER15> I think the scenario they're envisioning is one where the server generates an object, and some time later, wants to make sure it's getting back an object that the server has previously generated. HTTP cookies are a good example of this. Anything where you'd reach for JWT is probably also this use case.

> _his post is mostly about authenticating consumers to an API. ... you're > trying to differentiate between a legitimate user and an attacker, usually > by getting the legitimate user to prove that they know a credential that the > attacker doesn't._

The recipient of the API key doesn't need to verify their object. There's no attack from being able to give someone a fake API key - any attacker in a position to modify the API key in transit, which would just be a DoS, is also in a position to drop the connection, which is also a DoS. Such an attacker is probably also in a position to _steal_ the API key silently, which is a bigger problem. (If a client is really curious whether they have a valid API key, they can just make an API call with it and see if it works, they still don't need to actually check the signature.)

<comment><USER16> I don't think that's a fair assumption. Google IAP puts JWTs in headers to attest the end user's identity in a way you can't just forge from inside the firewall. Other use cases have you obtain a JWT from a dedicated auth service, maybe even a 3rd party provider, so that other random services don't have to know about passwords and 2FA. In both cases it would be prohibitively expensive to call back to the auth service to verify each token. The point of using a standard like JWT is to make it intelligible in other codebases, otherwise you could make your own format and serialization.

</comment></comment></comment><comment><USER17> > Anyway, no, because you need to parse a header to read the JWT, so you > inherit all of the problems that stem from that.

Can anyone enlighten me what point is the author trying to make? JWT is pretty damn standard so it's my go-to for signing objects.

<comment><USER3> We should write the "The JWT Problem" post one day, but this post isn't that, so I really don't want to derail the discussion.

The short version is that there are flaws in the JWT specification that make certain bugs likely. A classic example of the "you have to parse a header to use the JWT" problem is the HS256 vs RS256 confusion bug, where your JWT library would interpret an allegedly-HS256 (HMAC) JWT using RS256 (RSA) key material. The JWT would get validated using the public key of the RSA pair, interpreted as an HMAC key. But the public key is, you know, public! So the impact of the bug is that everyone can forge JWTs. That is not a problem that can happen in well-designed schemes.

We do have a blog post from last year that tells you what we think you should do if you want to be safe and you know what kind of abstract thing (e.g. signing, MACing, etc) you need: [https://latacora.micro.blog/2018/04/03/cryptographic- right-a...](https://latacora.micro.blog/2018/04/03/cryptographic-right- answers.html)

(Disclaimer: I'm the author.)

<comment><USER18> Assuming a JWT implementation accepts only a fixed header (all header fields must be present and match, no additional fields can be present), are there any other issues with "just use jwt"?

<comment><USER19> I do like using JWT. But its point is to offer flexibility. If you fix the entire header i.e. use a single signature method, you might just as well concat that signature directly.

In other words if you stop utilizing JWT, you won't have JWT specific problems.

</comment></comment></comment></comment><comment><USER20> > Canonicalization is a quagnet, which is a term of art in vulnerability > research meaning quagmire and vulnerability magnet. You can tell it's bad > just by how hard it is to type 'canonicalization'.

The funniest line from this article and my word of the day.

<comment><USER3> That one is all 'tptacek.

</comment></comment><comment><USER21> I'd go one step further: If you're in the situation that allows for HMAC over asymmetric signatures, you might as well go all the way with authenticated encryption instead of purely a MAC. Even if you have TLS, you still gain a minor benefit of having black box tokens to everything outside the system, in particular if you have to let untrusted or semi-trusted clients hold on to signed data that they needn't know the contents of. Yes, security through obscurity is not sufficient on its own, but can help stall analysis and exploitation efforts,

<comment><USER3> I don't think that addresses the problem set out in the post. Other, non- cooperative third-party systems need to be able to parse the JSON blob as is.

</comment></comment><comment><USER22> > Canonicalization is fiendishly difficult.

1000 times this! If you think you need canonicalization, always remember: "no you do not!" It is not a hill you want to die on.

<comment><USER23> While integrating with a large company's SSO protocol (with a cleanroom implementation), I found that the off-the-shelf "standard" XML DSIG canonicalization code they were using (from a major vendor) actually was not compliant with the W3C spec. That was unpleasant to have to discover and then explain.

</comment></comment><comment><USER24> More about use case than how to do it: client side certificate authentication is not a rocket science.

Unless you 100% need to use signing for the use case like a client side ACL, there is genuinely no need to overengineer your web app with your own authentication scheme.

But if your scale already mandates doing operations without server side ACL lookup for performance reasons, doing it over HTTP and web stack might already be inefficient by itself for the task.

<comment><USER15> Client certs are great if you control the client. If, say, Slack told me that to use the Slack API I'd need to get a client cert, I would laugh.

One thing that comes to mind is that either you have to check revocation on the server side, or you have to re-provision client certs frequently, and in most client libraries that's actually difficult / annoying. If the server just sends me an updated token, I can just put that in a local variable and call it done.

There's a reason most APIs have moved to "you can just put the token in the request payload". It's hard enough to ask people to set HTTP headers, asking them to set client certs will be super complicated.

<comment><USER24> > in most client libraries that's actually difficult / annoying.

You can add a client cert with just 2 clicks on Windows. To my experience, that's way easier than most API authentication schemes

<comment><USER15> One, on Mac and Linux it's more involved.

Two, I'm talking about client _libraries_ , not web browsers. Every client library (including those used by web browsers) is perfectly capable of passing a query parameter. Most can pass cookies or custom headers. Not all of them can pass client certs.

</comment></comment></comment></comment><comment><USER25> > Maybe you don't need request signing? A bearer token header is fine

If you're going to insist on symmetric key signatures, yeah. Otherwise a symmetric signature would be the same as using symmetric encryption to store user passwords, wouldn't it? You have to have the secret key to verify the user's signature.

<comment><USER3> I don't understand your analogy. Can you elaborate? I don't see the parallel between (a)symmetric signatures and encrypting passwords.

<comment><USER25> The article appears to say that you must sign your requests with a symmetric key. To verify the request, the server needs the same key, right? So the server needs a copy of every single user's encryption key.

The server _could_ just store the keys plaintext in a database but I'm assuming we can agree that's a horrible idea. The best it can do is encrypt them symmetrically before storing them, using an extra-special secret key that needs to be protected very carefully.

With username/password authentication, we don't store symmetrically encrypted passwords, do we? We store a one-way hash of the passwords instead, because symmetric is deemed not-good-enough.

<comment><USER3> The server is trying to validate that the thing it gets back is the thing it previously sent out, so that's a different model. What concretely are you suggesting we store as if it was a password? The serialized JSON object?

<comment><USER25> I'm beginning to think you're trolling, but... I'll make one last attempt to explain: How does the server verify the signature? Does it just wave a magic wand? Doesn't it need the same key the user used to sign the request?

<comment><USER3> As I mentioned in that comment: the thing sending is also the thing receiving, just at a later point. So "the same key the user used to sign the request" doesn't seem to apply.

<comment><USER26> It seems like you're describing a specific use case that is different from what most readers think of when they see a post about cryptographic signatures.

If the server generates the token, and all it's effectively doing is verifying that the client has the correct token, then what is gained by making that token be a signature of any sort?

<comment><USER15> You no longer have O(n) server-side storage proportional to your number of clients, the way you would if you put each token in a database. You also no longer need to worry about consistency + availability of that database if you have multiple web servers. If one web server in your cluster generates a signed token, and another one verifies it, they have the same key (they have exactly one key, among all of them) and it works without any communication or storage between the web servers.

<comment><USER26> That's fair, although it doesn't allow tokens to be revoked or to expire. For that you'd need to store at least some unique part of the payload you're signing, and then you have O(n) storage requirements again, right?

<comment><USER27> > or to expire

Add an expiry time to your signed payload. Tokens can have metadata.

> If the server generates the token, and all it's effectively doing is > verifying that the client has the correct token

I think you might be understanding "token" as the API tokens that are just a random bunch of bytes that are later matched to authenticate like they were a password (let's call them "passtokens", I don't know if they have a name).

Tokens can be far broader than that. For example, JWTs contain arbitrary data. Verifying that the token is valid is just verifying its signature. You wouldn't check that the passtoken matches (in fact, you wouldn't have a passtoken at all). The payload is where the sauce is at.

A payload can include anything, from an user id (which is similar to the passtoken use case, authentication) to a list of grants (so you wouldn't even have to hit the "users" table to check for permissions... or even have access to it! As long as you can verify the signature.)

> to be revoked

That's true though. This is usually handled with short-lived tokens that must be renewed periodically.

Alternatively you could have a Token Revocation List of some sort (which isn't O(n) storage since 1. not all tokens will be revoked and 2. you can purge expired tokens). But then you get the problem of synchronizing the TRL across services (or centralize the token verification in a service which IMHO kinda defeats the purpose).

<comment><USER15> The way I'd approach this is to treat "revocation" as meaning "after this user's current tokens expire, they can't refresh them," and make the token lifetime short enough that you're comfortable with it. Document that any API call can also include a "new_token": {...} field, and the client should update. On the server side, only try to refresh the token when it's close to expiring, and don't fail the API call if you can't reach the revocation server (just skip refreshing).

You still have a central server to track account status, but now it can be more like "a text file with a list of usernames on a single box running Apache, if it crashes we reboot it" and less like "a distributed, high performance, highly-available in-memory K/V store that's in the critical path for every request," which is going to make you a lot happier operationally.

Or you can push the list of usernames to revoke to each server, or something.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER28> It's not JSON, but I had a scenario like this where I wanted an in-band checksum on an archive of files. In the end it was indeed a file with the signature included in the archive itself, and the formula for computing it was basically the shasum of the shasums of `file .` sorted alphabetically, with the signature file itself excluded.

That worked out just fine, but I can see the argument that it's much harder to get to a canonical JSON representation than it is to get to a canonical "tree of files" representation. Indeed, it was easy enough in my case that the repo contained a shell script one-liner that would compute it, and that was the reference against which the "real" python implementation was validated.

<comment><USER3> That sounds like you found an alternative format where finding something canonical to sign is easy (files, the shasum CLI) and punted on canonicalizing the in-band signature (which is good!).

</comment></comment><comment><USER3> A super-awesome related project I didn't get a chance to work into this post (because it's entirely deserving of its own): [https://github.com/benlaurie/objecthash](https://github.com/benlaurie/objecthash)

To be clear: I think that's a niche use case and while I think ObjectHash does a great job of exploring it, I don't expect the median startup to need an ObjectHash implementation.

(Disclaimer: I'm the author.)

<comment><USER29> Why is it _better_ to do tricky message processing before we achieve confidence that the message is legitimate/ genuine?

Or is the argument that even though this is worse it's so useful we might really want to do it anyway?

<comment><USER3> Definitely authenticate first!

If there's anything I said that made you think otherwise, let me know: I would like to amend that so no-one else thinks I could possibly mean that. The initially recommended (unless you can do otherwise) approach in the blog post is clearly "tag at the end" and every other approach also validates first. If you're referring to ObjectHash: like I said, it's a very niche application, I don't expect people to use it, and yeah, it enables new use cases.

(I expect you'd still really be authenticating the ObjectHash somehow -- e.g. by sending it over TLS -- but that's out of scope for ObjectHash itself.)

<comment><USER29> Yes, I was referring to ObjectHash of course, since it's in the sub-thread about ObjectHash.

"I don't expect people to use it" just seems like the sort of awful excuse you'd usually be jumping on people for. It's like someone built a github project with a bunch of crypto red flags to check whether their new "Search github for projects with crypto red flags" idea works.

Don't get me wrong, it's clever, and I like clever. But I have learned in cryptography to only accept clever when it is clearly in the service of a specific pre-identified goal, and not just for its own sake. Isn't that normally a philosophy you'd subscribe to? What's the _pre-identified goal_ for this thing?

While we're here, another red flag. Mentioning Certificate Transparency as a model for some other X Transparency. Certificate Transparency isn't a model for anything. People have been saying to themselves almost from the dawn of CT "Oooh, this is clever, I should do the same for X" and it's always a bad idea. Someone might need a Merkle Tree. I'd argue they shouldn't use ObjectHash anyway. But the chance they need all the other paraphernalia from CT? Basically non-existent.

<comment><USER3> > "I don't expect people to use it" just seems like the sort of awful excuse > you'd usually be jumping on people for.

I think it was pretty clear, by calling it a specific niche that ObjectHash does a good job of exploring, that I am not making a recommendation.

</comment></comment></comment></comment></comment><comment><USER30> The "regex bait and switch trick" doesn't work if any of the intermediate processors might decode and re-encode the JSON.

<comment><USER3> That's an excellent point, you're of course right and the blog post could do a better job explaining that. I'll amend.

</comment></comment><comment><USER31> Seems that you just need to go ahead and build a canonical JSON encoder in JS. It would be slower but hey, you need the same consistent algorithm for signing. The encoder would be part of the spec.

<comment><USER7> JSON is UTF8, it's already canonical in that regard, if you don't f*ck with the serialized bytes tethered to the signature, you'll be absolutely fine.

<comment><USER3> Not in the sense that the term of art "canonical", as in canonicalization, is used. UTF-8 is not canonical: different byte sequences can map to identical meanings, as covered in the post.

<comment><USER32> I'm really confused by some of the assumptions in this whole thread, sorry. In what scenario would a client touch the string it authenticates and parsed JSON from before sending it back to the server later? This argument seems to assume that I have to throw away the string I've parsed or somehow reconstruct the same JSON and create the HMAC myself locally, which seems odd.

<comment><USER3> I think I may have answered your confusion in a different thread (I'm not sure I parsed your comment correctly though), but: this is about a problem that specifically occurs when you have JSON (or some other structured format) that needs to have the signature in-band. You're right that it's way easier (the first list of three bullet points, as you mentioned inthe other comment thread) if you can just shiv the tag on the outside.

Perhaps a more familiar case where this happens is SAML assertions with inline signatures?

<comment><USER32> Yeah, thanks, since you likely encountered these scenarios I guess we're just looking at it from very different viewpoints and some of mine might be lost in translation.

Luckily the number of times I've had to invent signing schemes or even integrate SAML is limited. :)

</comment></comment></comment></comment></comment></comment><comment><USER33> Looks good. I'm missing ACME request signing in comparison.

</comment><comment><USER7> I actually prefer JWT with an asymmetric key. Anyone can confirm the payload's providence. HTTPS takes care of encryption for the payload. Of course with JWT, only allow trusted keys or signed keys from a trusted CA.

There have been some poor implementations, but the method is pretty sound.

</comment><comment><USER34> Howto prove you are a God:

Create a json file

        {"msg":"I am a God. My name is Bob.",
         "sha256":"78A873E..."}

where the hash is the checksum of the file including the checksum. It would be equal to finding fixed point in cryptographic hash function that happens to be checksum to your message.

<comment><USER15> That's pretty easy to do with MD5 :) [https://twitter.com/i/moments/838685002703466497](https://twitter.com/i/moments/838685002703466497)

</comment></comment><comment><USER35> A fatally flawed post that dooms it to the category of SEO rather than what should be useful information. I did especially like:

> Canonicalization is a quagnet, which is a term of art in vulnerability > research meaning quagmire and vulnerability magnet. You can tell it's bad > just by how hard it is to type 'canonicalization'.

The flaw?

There's nothing here not already well known, so this isn't an insightful piece for those already well versed. Therefore, this is a piece written for those that aren't so practiced, for the sake of discussion: junior dev or devops, or non-security devs.

The content itself _is_ a good discussion, and digestible (lol).

But, as a piece that junior folks are expected to get a takeaway from, the introduction is a disaster:

> This post is mostly about authenticating consumers to an API.

ie, not service-to-service auth.

> Unless you have a good reason why you need an (asymmetric) signature, you > want a MAC.

A MAC/HMAC requires the signer and all verifiers to have the key. As stated just prior, this is about "frontend" signing. A novice reader might not realize they have to guard the key very well, and might even send it to the client browser. "Unless you have a good reason" is not a sufficiently strong warning for a post that is written as an instructable, more or less.

More architectural introduction (bonus with diagrams) is required. As is, this post is a footgun.

<comment><USER32> Not sure why you are downvoted, about 10% of the article addresses it's headline and I frankly do not get the point either. The proposed solution is in the first numbered list and between that and the conclusion list is a bunch of prose on non-JSON payload.

The only slightly JSON related content in there is a constructed scenario for 'in-band' signatures (the regex thing) which can just as well be achieved by a bit of string processing. Any JSON object will start with {, end with } and have some more information between it. Replacing the initial curly brace with '{"hmac": "foo",' gives you a valid JSON document. You can remove that easily before parsing and place no restrictions on the object's keys. You can handle edge cases like JSON literals or arrays by wrapping the whole thing in {"hmac": "foo", "payload": yourstring} if you feel like it.

<comment><USER3> > Not sure why you are downvoted, about 10% of the article addresses it's > headline and I frankly do not get the point either. The proposed solution is > in the first numbered list and between that and the conclusion list is a > bunch of prose on non-JSON payload.

The proposed solution is not in the numbered list. The numbered list describes how to sign a JSON blob from the outside. The rest of the doucment describes what you do if that's not an option, and you need to sign the blob in-line. The very next paragraph after said numbered list describes how to do that.

(I'm the author.)

<comment><USER36> _(I 'm the author.)_

Whee, I can stop rage-typing 'how not to self-attribute your comment about a thing you wrote' now!

<comment><USER3> Huh, sorry, I'm confused. What should I (not) be doing? I thought not disclosing being the author of the linked thing was poor form.

<comment><USER36> Oh it's nitpicker than that - you don't have to 'disclaim' being the author cause, you're, you know, the author and can just say you are.

<comment><USER3> Ah! So you're saying I should say "Full disclosure" and not "Disclaimer"? (Or nothing at all, as I do here, I suppose :-)) Yes, you're absolutely right and I'll try to do better in the future :)

<comment><USER36> 'Disclosure' is something journalists use to point out a potential external conflict/relationship the reader might unaware of. But you don't need it to point out authorship either. You're really saying 'I want you to be aware I wrote the thing we are discussing' not 'Please don't think I'm sockpuppetting for myself'.

This is a bit like an even more persnickety version 'nation state' in that the trivial fix is just dropping the pointless ceremony.</comment></comment></comment></comment></comment></comment></comment></comment>


Diaspora-common: does 'rm -rf /' on purge - <AUTHOR> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858521 <comment><USER2> All scripts should be run with "-eu". This prevents unbound variables from ever being used and will end the script on a failed command. If you want commands in the script to fail, just drop the "e" and run with "-u". At my last job we put "-eu" in literally all of our scripts to avoid this very problem.

<comment><USER3> _> All scripts should be run with "-eu"._

More specifically, every shell script should have "set -eu" at its second line, directly after the sh'bang line:

        #!...
        set -eu

For debugging or logging purposes, sometimes adding -v and/or -x comes handy:

        #!...
        set -euvx

<comment><USER4> > should have "set -eu" at its second line

Do you have a strong reason to prefer "set" over shebang flags? I have a slight preference for shebang flags so I can deliberately override them from the command line (but it's not a hill I'd die on):

        $ cat foo
        #!/bin/bash -eu
        cd /nowhere
        echo 'still here'
        $ ./foo
        ./foo: line 2: cd: nowhere: No such file or directory
        $ bash -c ./foo # thinking about system(3)
        ./foo: line 2: cd: nowhere: No such file or directory
        $ bash +e ./foo # override
        ./foo: line 2: cd: nowhere: No such file or directory
        still here
        $

EDIT: Google's shell style guide has "Executables must start with #!/bin/bash and a minimum number of flags. Use set to set shell options so that calling your script as bash <script_name> does not break its functionality."

[https://google.github.io/styleguide/shell.xml?showone=Which_...](https://google.github.io/styleguide/shell.xml?showone=Which_Shell_to_Use#Which_Shell_to_Use)

<comment><USER3> Bash is not always /bin/bash. On some systems (BSDs) it is /usr/bin/bash.

So the portable sh'bang line for bash is:

        #!/usr/bin/env bash

And there you can't add "-eu" anymore, because only one argument is possible in sh'bang lines. (/usr/bin/env would try to find an executable named "bash -eu")

So

        #!/usr/bin/env bash
        set -eu

is the more portable approach. However, for "/bin/sh" this should work portably:

        #!/bin/sh -eu

<comment><USER5> > Bash is not always /bin/bash. On some systems (BSDs) it is /usr/bin/bash.

Nitpick: on every BSD system I've used, it's /usr/local/bin/bash. But I definitely agree that using /usr/bin/env bash is the preferred solution for when you want to use bash (although I don't think it's even installed by default on most BSD's); as an Arch user (where /usr/bin/python is symlinked to python3 rather than python2), I appreciate those who go out of their way to use proper, portable shebangs.

</comment></comment></comment></comment></comment><comment><USER6> From reddit:

> It's actually rm -rf /bin.

> Seems to be caused by the same reason as the famous Steam bug - using an > undefined variable. Plus the default bash behavior that simply ignores the > fact that it doesn't exist and treats it like an empty string.

> tl;dr flamebait: The Unix way™ of "everything is just text" strikes again. > (EDIT: yes this a gross over-generalization)

source: [https://www.reddit.com/r/programming/comments/610z2f/858521_...](https://www.reddit.com/r/programming/comments/610z2f/858521_diasporacommon_does_rm_rf_on_purge/dfauurn/)

<comment><USER7> Creating the same bug in a code tree editor would certainly not help anything.

<comment><USER8> I think the alternative being suggested is that rm shouldn't accept a string that magically can reference anything in the filesystem...

In our capability-based shell scripting language Shill (shill-lang.org) for example, you could prevent this sort of bug by giving the script a capability for just the diaspora_home directory, and deriving the child directories from that capability. (Of course, you still need to make sure you pass in the right directory in the first place.)

<comment><USER9> _I think the alternative being suggested is that rm shouldn 't accept a string that magically can reference anything in the filesystem..._

That suggestion fails to grasp the basics of Unix shells however: parameter expansion as well as globbing is performed by the shell, rm "sees" nothing but fully-expanded paths.

</comment></comment></comment></comment><comment><USER10> Wildcards and variables in "risky" commands are a way of favoring convenience over safety and auditability, favoring writing (done rarely) over reading (more frequent). They are also unlikely to stand the test of time because the meaning can change, casting a different net than you originally intended.

If a command is risky, you should at least GENERATE the variable-expanded list of inputs (e.g. in a separate file) so that the list can be audited. For instance, basic automatic sanity checks can be performed on the expansion like "length > 1", and you can see every affected item. It also acts as a log of impacted things in case it _does_ run.

Robust code is not always convenient.

</comment><comment><USER11> Sure, this is a good idea (from the proposed patch):

        +        # safety check
        +        [ "${diaspora_user_home}" != "" ] || exit 1
        +        [ "${diaspora_home}" != "" ] || exit 1

... but this is key IMO:

        +# Abort if any unbound variables are used
        +#set -u

I often use "set -euo pipefail" in my bash scripts. It does come with some caveats, though.

<comment><USER6> To be fair, the proposed patch says on the box that it's "completely untested". The author seems to be politely saying that the package is a hot mess, and my impression was that they weren't willing to put any more time into it.

<comment><USER12> My impression was that the submission of the untested patch ("testing welcome") was that it was a fast first step in collaboratively fixing the issue.

</comment></comment></comment><comment><USER13> I still think a package manager should never execute any code at all. It should extract a package and remove its files at some point again, but that's it.

<comment><USER14> That would require a reorientation of the whole distribution around the requirement that packages integrate only at the level of whole files. Everything from interacting services to user and password management, from drivers to application plugins, all of it would need to be integrated solely using atomic files on disk. Anything that couldn't be packaged that way would need to be rewritten or forked. You're essentially asking for a whole new operating system.

<comment><USER15> Doesn't Nix offer at least an attempt at this?

<comment><USER16> Nix offers a very good attempt at this. There are some exceptions at the NixOS level, but they're kept to a minimum; mutable state is largely kept to just restarting/starting/stopping systemd services when the system changes.

And /etc is not among the exceptions; it's built as a package, just like nearly everything else. If something goes catastrophically wrong, you can still roll your system back to a previous version. (Through GRUB, if it's completely broken.)

For a concrete example, /etc/passwd is generated by a single NixOS module -- that is, Nix code. That module reads a list of users provided by other modules, and makes sure to e.g. avoid any duplicates. It's impossible to switch the system into a state where two users have the same UID, so while rolling back from that would be doable, you can't get there in the first place and (nonexistent) purge code could not be run.

</comment></comment></comment></comment><comment><USER17> Looks like that script could benefit from a couple of rounds of ShellCheck. [http://www.shellcheck.net/](http://www.shellcheck.net/)

<comment><USER18> ShellCheck warned me of a very similar issue in a script of mine recently. In that script I ran the following:

      rm -rf "${FOO}/"

ShellCheck helpfully warned me that that could have disastrous consequences when FOO is unset, instead it advised me to use this:

      rm -rf "${FOO:?}/"

I'd also like to point out that ShellCheck is in the AUR for users of Arch Linux[0], and that there's a handy plugin which I use for the Atom editor[1].

[0] [https://aur.archlinux.org/packages/shellcheck- git/](https://aur.archlinux.org/packages/shellcheck-git/)

[1] [https://atom.io/packages/linter- shellcheck](https://atom.io/packages/linter-shellcheck)

<comment><USER19> There is also a plugin for sublime text [0] It doesn't take long to internalize the corrections. It's well worth using a linter if one is available.

[0] [https://github.com/SublimeLinter/SublimeLinter- shellcheck](https://github.com/SublimeLinter/SublimeLinter-shellcheck)

</comment></comment></comment><comment><USER20> I'll take this opportunity to plug my most popular essay of all time here:

[http://redsymbol.net/articles/unofficial-bash-strict- mode/](http://redsymbol.net/articles/unofficial-bash-strict-mode/)

Looks like it might have prevented this.

</comment><comment><USER21> And its fixed already in [https://anonscm.debian.org/cgit/pkg-ruby- extras/diaspora-ins...](https://anonscm.debian.org/cgit/pkg-ruby- extras/diaspora- installer.git/commit/?id=7071a253e8404e41e7767b4330899a2da045731c)

<comment><USER22> This is not a particularly good fix.

It lacks "set -u" which is the first line of defense for this kind of bugs, much more robust than the "if [ -d ...".

Command lines lack proper shell quoting. If $diaspora_home ends up with a trailing space somehow, this will again end in a disaster.

I don't see the point of adding a "test -e".

It seems "rm -rf /var/cache/diaspora /var/log/diaspora" got lost, so these directories are no longer cleaned up after uninstall.

<comment><USER23> Well, feel free to submit a patch with an explanation: you'll improve the situation, and others will learn from it!</comment></comment></comment>


Gold, silver, platinum: experts can't distinguish the difference in sound - <AUTHOR> http://iwk.mdw.ac.at/Forschung/english/linortner/linortner_e.htm

<comment><USER2> Many years ago, I was told by a flute teacher that the main difference between beginner (i.e. cheap) flutes and the better models is that the inside of the air hole in the better models is shaped slightly differently to give a very subtle indentation just below the edge of the hole. Since this fine tuning has to be done by hand, it raises the cost (although I suspect that with all instruments now being made in Asia, the labour costs today would be negligible).

I'm sad that I can no longer blame my lousy tone on not having a solid gold flute. :(

</comment><comment><USER3> In related news, expert violinists can't distinguish between Stradivarius violins and newer ones:

[http://www.npr.org/blogs/deceptivecadence/2012/01/02/1444828...](http://www.npr.org/blogs/deceptivecadence/2012/01/02/144482863/double- blind-violin-test-can-you-pick-the-strad?sc=fb&cc=fp)</comment>


On the arXiv: dolphin echolocation algorithm for automatic knot adjustment - <AUTHOR> https://arxiv.org/abs/1701.04383 <comment><USER2> Man, metaheuristic algorithm designers are so creative in finding ways to avoid mathematical justification....

</comment><comment><USER3> Here [0] is the paper describing the Dolphin Echolocation Algorithm used in this paper. Very interesting method, looks like it has real advantages compared to the usual optimization algorithms.

[0] [https://www.researchgate.net/profile/A_Kaveh/publication/257...](https://www.researchgate.net/profile/A_Kaveh/publication/257424785_A_new_optimization_method_Dolphin_echolocation/links/564620af08ae451880aa336a.pdf)

</comment><comment><USER4> Looking at the paper, it looks like an optimized Genetic Algorithm.

</comment><comment><USER5> I really don't trust the journal that this is published in. See [http://macrojournals.com/](http://macrojournals.com/)</comment>


Apple Open Sources iOS Kernel - <AUTHOR> https://github.com/apple/darwin-xnu <comment><USER2> XNU has always been open source, but not the iOS specific changes. There have been private efforts to compile it for ARM, but this is now officially supported in the public Apple source code.

<comment><USER3> But is this compilable and usable for a bare iron iphone or mac? Or even vm?

<comment><USER4> Not in it's current state. It's just a kernel. It's missing key components of the software stack to even make it terminal-only, let alone a GUI. There have been attempts through the years to create a full OS from the bits of OS X/macOS that Apple drops on opensource.apple.com. They do this by surrounding the kernel with FreeBSD or GNU software land, porting Xorg, and other components. See DarwinBSD, OpenDarwin, and PureDarwin. None of the projects proved sustainable in the long-run. It is possible that could change now though with better access to the code on GitHub. It's also possible we could see better drivers developed for hackintosh.

</comment></comment></comment><comment><USER5> I think this title is misleading. Apple has open XNU for more than 10 years. And AFAIK this kernel does not include ARM compiling option, as the very first paragraph in the README:

> XNU runs on I386, X86_64

<comment><USER2> That's what's newsworthy here—the code now includes the ARM codepaths as well.

</comment></comment><comment> unkown-unknowns This should not be flagged. The title is correct. There is code specific to arm and arm64 in the repo, whereas previously the public source code releases were only i386 and amd64. Apple has open sourced the iOS kernel. Please unflag.

</comment><comment><USER6> How long has this been a thing? This seems huge, but I don't spend enough time in the iOS ecosystem to tell if this is just how it's been for months/years

<comment><USER7> This only dropped 2 days ago

<comment><USER8> It's been on opensource.apple.com for a decade. This Github repo is just a mirror.

</comment></comment></comment><comment><USER9> If they start taking PR's and merging in, that would be awesome. I'm sure there's lots to be optimized and improved.

<comment><USER10> > If they start taking PR's

It's a mirror.

</comment></comment><comment><USER11> Perhaps this could have something to do with the rumors of ARM Macbooks?

<comment><USER12> Likely.

</comment></comment><comment><USER13> Title should be "Apple now has a mirror of XNU kernel on Github"

</comment><comment><USER14> Why is this flagged?

</comment><comment><USER15> Why is this flagged?</comment>


Android 4.0 Ice Cream Sandwich update for Samsung Galaxy S2 delayed once again - <AUTHOR> http://www.geeksailor.com/android-4-0-ics-update-for-samsung-galaxy-s2/

<comment><AUTHOR> Android manufacturers have serious issues with upgrades. This is key to compete with Apple where you can enjoy a new operating system very quick.

Yes, there are multiple devices but is this an excuse? Samsung is a top manufacturer.</comment>


Ask PG/HN: Why does the number of previous comments count in comment ranking? - <AUTHOR>

I'm trying to figure out how I can be a better member of the community (thereby, presumably, gaining more karma), and looking through my old threads I noticed that often, even when my comments have the most points on a story, and even when my karma isn't any lower than the other people commenting, my comments are at the bottom of the page.  The only thing I can find that could cause this is that I've posted 22 comments while others have consistently posted more.  My "average karma" is nil, and I assume this means I haven't posted enough to begin its tabulation, and I remember recently PG said something about revamping comment ranking to include this statistic.<p>I can understand a sort of "probation period," in which new users are expected to spit out solely inane things, but I have a number as low as 22 because I generally only comment when I feel my comment seriously adds to the discussion, and (I feel) not because of a lack of familiarity with the community.  On SearchYC, my average comment score is 4.86.  I assume that I'm not being singled out, and that other people are in this situation as well.  So, is there an explanation I'm missing here? <comment><USER2> Your comment average doesn't get calculated till you've made over a certain number of them.

</comment><comment><USER3> I'll let someone else (who has actually bothered to look at the source code) speak about the details, but I believe that the major factor you're forgetting is comment age.

In any event, the best general advice is not to worry too much about the karma mechanisms, and just try to make the kinds of comments you think contribute best to the discussion.

<comment><AUTHOR> Sorry, but I don't think that's it.</comment></comment>


The Meaning of $ and # Symbols in the Terminal - <AUTHOR> https://askubuntu.com/questions/1192139/meaning-of-and-symbols-for-normal-and-root-user-in-terminal <comment><AUTHOR> TL:DR

$=work (money; where you will earn your living)

#=danger (it could go bad and you'll see the "#"'s as appeared then on batman tv shows instead of hits or violence)

<comment><USER2> The correct answer is that # is the comment character. When the root prompt is #, then the entire command session looks like it is commented out. This prevents disasters if you accidentally copy it and paste a range of the content of the terminal backlog. Or mail a copy to someone who just blindly does a paste into their terminal.</comment></comment>


Statistical Machine Learning, Spring 2016 - <AUTHOR> http://www.stat.cmu.edu/~larry/=sml/ <comment><USER2> For those of you interested in this stuff, this course (10-702) is the second in a series. The 10-701 course, "Intro to Machine Learning", is a fantastic course as well, even if just for the exercises. This year's version is here [1], you can find lecture notes, links to lectures posted on YouTube, homeworks, readings, etc. You can also just google "10-701" and see a lot of previous course websites with similar material.

For what it's worth, nowadays, the problem isn't availability of learning material. This stuff is being literally given away. Its that you, the student, has to really dedicate time to the material. The first homework assignment for the 10-701 class wasn't even that difficult (relatively speaking) and it still took me over ten hours to finish. Persevere! It's worth it.

[1]: [http://www.cs.cmu.edu/~mgormley/courses/10701-f16/](http://www.cs.cmu.edu/~mgormley/courses/10701-f16/)

<comment><USER3> Thanks! One thing that can definitely set a course apart is having advanced topics + downloadable videos + captions. I really enjoyed the Stanford NLP CS224d videos, which hit all 3 and even have their own torrent [1].

Does anyone know if there's a platform for crowdsourcing video captions, maybe from the anime world?

Edit: it appears as though you can correct the auto-generated captions on Youtube videos (perhaps only if you're the owner). What a great way to get labeled Speech Recognition data for free.

[1] [http://academictorrents.com/details/dd9b74b50a1292b4b154094b...](http://academictorrents.com/details/dd9b74b50a1292b4b154094b7338ec1d66e8894d)

<comment><USER4> I would add assignment solutions to your list of desirable things. Makes it easy to keep moving after getting stuck.

<comment><USER2> [http://www.cs.cmu.edu/~epxing/Class/10701/](http://www.cs.cmu.edu/~epxing/Class/10701/)

[http://www.cs.cmu.edu/~aarti/Class/10701_Spring14/](http://www.cs.cmu.edu/~aarti/Class/10701_Spring14/)

[http://www.cs.cmu.edu/~./10701/](http://www.cs.cmu.edu/~./10701/)

[http://alex.smola.org/teaching/cmu2013-10-701/](http://alex.smola.org/teaching/cmu2013-10-701/)

All of the above have answer keys for the homework assignments.

</comment></comment></comment></comment><comment><USER5> Recent CMU alum here ('15). 10-701/702 are the intense higher level courses meant for ML PhD students. If you want something a little less mathematically rigorous and a little more application focused, consider the masters version of the course, 10-601. All if its material is available here online as well [1]. That said, if you are willing to put in the effort and have the mathematical background to tackle 701/702, you definitely won't leave disappointed.

[1] [http://www.cs.cmu.edu/~roni/10601/](http://www.cs.cmu.edu/~roni/10601/)

<comment><USER6> Well, now we have 10-715 as the ML PhD-level course that corresponds to 701. [https://www.cs.cmu.edu/~epxing/Class/10715/](https://www.cs.cmu.edu/~epxing/Class/10715/)

<comment><USER7> Here's a comparison of the courses. Both are aimed at PhD students, one for students in the Machine Learning Department and one for students in other departments (including CS).

Edit: Whoops, forgot the actual link: [http://www.ml.cmu.edu/teaching/ml- course-comparison_11.2015....](http://www.ml.cmu.edu/teaching/ml-course- comparison_11.2015.pdf#Intro%20Course%20Document)

</comment></comment></comment><comment><USER8> Kevin Murphy - "Machine Learning: A Probabilistic Perspective" is a great (literally - 1000+ pages) textbook that is basically self-contained (pre-reqs: some comfort w. multivariable calculus, linear algebra, basic computer science theory; convex optimization experience a huge plus)

<comment><USER9> Yikes, quite the tome. Looks great though, I've been looking for something relatively self contained. Does it have exercises for each chapter, and if so are solutions also available?

<comment><USER8> Every chapter has exercises. One example from Ch. 14 - Kernels is this:

> Exercise 14.2 Linear separability

> (Source: Koller..) Consider fitting an SVM with C > 0 to a dataset that is > linearly separable. Is the resulting decision boundary guaranteed to > separate the classes?

etc. Many exercises are proofs or derivations, and the book is full of (algorithm/optimization) defining/bounds approximation/ otherwise pragmatic information.

</comment></comment></comment><comment><AUTHOR> The professor is Larry Wasserman of the "All of statistics" fame.

<comment><USER10> Heard good things about it - thanks for pointing the connection

</comment></comment><comment><USER11> Interesting...seems like all the content is available. Last I remember, you needed a CMU ID to access the course materials.

<comment><USER12> They don't have to care about giving content away.

The golden goose is the degree which is kept in artificially short supply and very expensive.

<comment><USER4> That is a true blessing in disguise.

<comment><USER12> How so?

</comment></comment></comment></comment><comment><USER13> I looked at assignment #1 and realized just how dumb I am (not a bad thing, just a statement).

I am interested in Machine Learning, but I'm going to seek out the intro material first and come back to this (much later).

</comment><comment><USER14> Damn it, maybe machine learning isn't for me. I took this class CSE-191 and I sucked bad at it, similar to this with proofs, logic statements. Fuck

<comment><USER15> Back in school, the harder proof based math courses were a big change for me. They took a while to get the hang of and even more years to really appreciate. Stick with it and you can get good at it. It's not innate.

<comment><USER14> It just like... I don't know normal math it "works" you can work through it step by step, this stuff is almost like philosophy to me... where it didn't really make sense, you just took it for word what some guy thought. I did badly in philosophy but did well in psychology.

not saying this doesn't follow a set of rules/logic, I'm just saying I look at it and it's not like rote-memory math, you know, you look for these patterns, practice this method/approach and solve the problem...

yeah also it's a matter of passion too... I'm not actually sure what I'm passionate about, I thought I knew... but things like AI, Machine learning, computer vision, it's cool, but would I actually obsess over it and master it... I'm not sure. I'm still trying to solve the problem of "I need money" and I try to come up with ways to make a lot at once somehow, but not succeeding.

</comment></comment></comment><comment><USER16> How is it that many of these websites haven't learned about HTTPS, I.e. data integrity?

</comment><comment><USER17> Is there similar introductory courses on deep learning?

<comment><USER7> Nando de Freita's "Deep Learning" course taught at Oxford, 2015.

[https://www.cs.ox.ac.uk/people/nando.defreitas/machinelearni...](https://www.cs.ox.ac.uk/people/nando.defreitas/machinelearning/)

</comment></comment><comment><USER18> I bookmarked three weeks ago (busy with a few other edX and Coursera courses), and the page has a link to a free PDF book "An Introduction to Statistical Learning, with Applications in R":

Stanford Online: Statistical Learning

[https://lagunita.stanford.edu/courses/HumanitiesSciences/Sta...](https://lagunita.stanford.edu/courses/HumanitiesSciences/StatLearning/Winter2016/about)

Quote: "This is an introductory-level course in supervised learning, with a focus on regression and classification methods. The syllabus includes: linear and polynomial regression, logistic regression and linear discriminant analysis; cross-validation and the bootstrap, model selection and regularization methods (ridge and lasso); nonlinear models, splines and generalized additive models; tree-based methods, random forests and boosting; support-vector machines. Some unsupervised learning methods are discussed: principal components and clustering (k-means and hierarchical)."

"This is not a math-heavy class, so we try and describe the methods without heavy reliance on formulas and complex mathematics. We focus on what we consider to be the important elements of modern data analysis. Computing is done in R. There are lectures devoted to R, giving tutorials from the ground up, and progressing with more detailed sessions that implement the techniques in each chapter."

List of courses: [https://lagunita.stanford.edu/](https://lagunita.stanford.edu/)

<comment><USER19> I'm working my way through this right now and highly recommend it. The book is excellent and the professors are personable and genuinely enthusiastic about the subject matter.</comment></comment>


WatchMouse site monitoring dashboard widget - <AUTHOR> http://www.watchmouse.com/en/widget/dashboard_widget.php

<comment><AUTHOR> It's not exactly enterprise material, since AFAIK it only works when your laptop is on, but it's nice if you have a few non-critical sites you want to keep an eye on.</comment>


The 50 richest people on earth - <AUTHOR> http://www.businessinsider.com/50-richest-people-on-earth-2016-1/ <comment><USER2> * The 50 publicly recognized richest people on Earth. *

Putin [1] is a great example of how little we know about who holds the real money, and the real power. Also the blurbs about each of the fifty were a little to cheery for what some of them probably did to gain their money (especially those from corrupt countries).

[1]: [https://www.washingtonpost.com/news/worldviews/wp/2015/02/20...](https://www.washingtonpost.com/news/worldviews/wp/2015/02/20/is- vladimir-putin-hiding-a-200-billion-fortune-and-if-so-does-it-matter/)</comment>


BiwaScheme (is a Scheme interpreter written in JavaScript) - <AUTHOR> https://www.biwascheme.org/ <comment><USER2> Pretty typical that it doesn't have hygienic macros. Scheme is mostly a pretty simple language to implement. Even things like call/cc is easy if you transform it to CPS.

Hygienic macros however is very much not a simple thing. You usually just copy one of the existing implementations.</comment>


Please help need advice. What should I do? Feeling very depressed. - <AUTHOR> Hi All
I am feeling really depressed. Someone newbie of my field with less experience made a very good impression in the community. While I was trying hard to make some impact for years and tried to enter in the field but not able to so much successful and he come and got all the glory.
Sorry I know it is wrong to be jealous. I got so much depressed and feeling very bad and insecure. I am also feeling so much anxiety.
Please help. Need advice. What should I do to overcome this thing. <comment><USER2> A. I recommend people never have -one- thing they do. Having -one- thing makes you dependent on the outcomes of that one thing, which will ebb and flow. Start putting energy in something else as well (I especially recommend strong relationships, or a physical activity pursued at the hobby level), and when your original project hits a low point, use your other activity to recharge.

B. Are they really newbie? Did they do 5 years of work in obscurity, and you just saw the point where they broke through?

C. Community glory tends to be a 'winner-takes-all-affair'. 8 people get 10% each, 2 people get %40 each. Try to live your life such that such long-shots are capable of enhancing it, rather than depending on it for your happiness.

D. You're not your status in the community. You're a worthwhile person for existing.

All of that is what you should focus on to not be so outcome dependent, and thats what I would suggest focusing on right now. There's also the legitamte question of how to have more of an impact on your chosen field, but I think that would require more ifnromation.

</comment><comment><USER3> Talk a walk. The military has soldiers do a huge amount of exercise to immunize them against combat stress. Also see a pcp and try an ssri, I don't believe the official explanation of how they work but they are cheap, easy to try, safe, and often help resilliance in the face of stress -- unlike benzodiazepines they treat anxiety without interfering with the natural process of maturing and getting better at handling situations or any attempt to do the same with various therapies.

</comment><comment><USER4> I've always thought it's easier to make a good impression when first entering a new field/job/school/whatever, the real trick is maintaining that good impression for a long-period of time. One success will buy you a certain amount of 'credit', but eventually it runs out. Longevity and endurance are the key.

But you should also think about working with this newbie, perhaps together you could achieve even more success?

</comment><comment><USER5> When I was depressed I did the following: [http://qr.ae/RgsEWk](http://qr.ae/RgsEWk)

With regards to your specific situation I'd like to add that perhaps it's wiser to stop working on a community project and perhaps focus on a new project, an idea, just by yourself. Try to make it a success in any way and be proud of yourself.

</comment><comment><USER6> Well this really helped me in my situation, hope you will also feel good:

[https://docs.google.com/viewer?url=https://ghurfa- books.s3.a...](https://docs.google.com/viewer?url=https://ghurfa- books.s3.amazonaws.com/19.-A_life_of_piety.pdf)</comment>


Why the Brain Seems Mostly Dormant (2015) - <AUTHOR> http://nautil.us/issue/27/dark-matter/heres-why-your-brain-seems-mostly-dormant <comment><USER2> I've always wondered what happens when a neuron's charge is decreased but doesn't hit spiking levels.

From the sounds of this there's always neurotransmitters being sent, even when there is a small change in voltage.

If a neuron with many dendrites is connected to a bunch of these non-firing neurons then I suppose it could fire, given enough small changes from upstream.

EDIT: link to what's considered "quiet" neurons in the article [https://en.m.wikipedia.org/wiki/Non- spiking_neuron](https://en.m.wikipedia.org/wiki/Non-spiking_neuron)

I also remember reading this interesting book that suggested neurons "feed" on the spikes. If they don't spike for long enough they get weak and potentially die. I'm not sure how that explains the article though.

<comment><USER3> Neurons will always be firing at some low level background rate, in biology I think the focus is more on the rate of fire than on individual spikes, and as far as I remember if that's all a neuron ever does it will indeed atrophy.

The best book on the subject for me is "How Brains Make Up Their Minds" by Walter J. Freeman, not only is it a short book which explains the real observed activity of neurons, but it is also backed up by an extremely strong vein of philosophy for meaningful interpreting the observations.

</comment></comment><comment><USER4> A joke of sorts I've heard before (usually in response to someone bringing up the 10% of the brain quote) is "Did you know the human brain uses only 10% of its vocabulary?"

<comment><USER5> It is the same with mathematics and most sciences. Learn 1000 things so you know when to use 10 of them.

It is impossible to know all the uses for complex things without actually understanding them.

It is impossible to be a general learner without a free enough latent space.

Tradeoffs are inherent in life and the universe...</comment></comment>


Processing 2.0 will "compile" to JavaScript - <AUTHOR> http://wiki.processing.org/w/Changes <comment><AUTHOR> Some additional info to reduce some apparent confusion.

I learned about Processing 2.0 from here:

[http://www.creativeapplications.net/processing/generative- ar...](http://www.creativeapplications.net/processing/generative-art-in- html5-processing-javascript-tutorial/)

I already knew about the IDE modes; being able to generate an Android app straight from Processing code is pretty slick (especially as you mix in stuff like Pure Data) though it has some limitations.

The above link adds, "Processing 2.0 adds a third option, 'JavaScript', which allows you to publish direct to HTML5 Canvas (using the now in-built Processing.js). And it works. It just works."

The best Processing page I could find that included this was the changes page, which also nicely lists other new features.

I picked the word "compile", in quotes, because while see as in fact compiling, I also tend to think of compiling as taking a high level level and outputting something lower-level. Though that's not a necessary condition, I had a feeling that if I left off the quotes there'd be complaints about how this wasn't _really_ compiling, title is misleading, etc.. But there you go.

edit: also, video: <http://vimeo.com/28117873>

</comment><comment><USER2> This could be useful. However, if this is done by using Processing.js, then there are some gaps that need to be addressed. Last time I checked, the JavaScript version does not support vlw fonts and loads fonts differently. There is also the file IO that is not supported in PJS.

</comment><comment><USER3> I can find nothing on that page that says it will compile to JS. I see a sister project that appears to interpret Processing code in a browser, but nothing about compiling to it.

<comment><USER4> If you look at the modes section on the change list they mention that processing.js will be a mode in the standard Processing IDE along with standard and android. Up until now Processing.js has always been separate from the official Processing release.

<comment><USER5> So there will be an "official" JS VM but there will be no actual compilation. Title should be updated IMHO.

<comment><USER6> My understanding is that Processing always "compiles" (or more accurately, transliterates) to some other language -- originally Java and now JavaScript as well.

<comment><USER7> A source-to-source compiler is still a compiler, and it still _compiles_. Transliteration implies that there is a one-to-one mapping between concepts in the source language and the target language, which is rarely the case. (If so, why bother with another language? Some of the languages which are a more readable CSS may come close, but my understanding is that they still have a few abstractions that don't exist in CSS.)

<comment><USER8> The main case of transliteration I can think about is assembly language.

<comment><USER7> Yes, good call, there is a one-to-one mapping between assembly language and machine code.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> Lame title.

Saying that it will compile to JavaScript implies (or at least suggests) that it will no longer compile to Java.

The page clearly says that JavaScript will be one of several "modes". C'mon.</comment>


OVH Datacenters "electrical outage", support, status down too - <AUTHOR> http://status.ovh.ie/?do=details&id=15162&PHPSESSID=972347f3eb45fa4c5911dcb904ed3679 <comment><USER2> The Rubaix datacenter is down too. So are the status pages. This is a major disruption!

[https://twitter.com/olesovhcom](https://twitter.com/olesovhcom) [http://currentlydown.com/ovh.net](http://currentlydown.com/ovh.net)

Edit: now they said:

> The optical network in Europe which interconnects RBX and GRA with POPs. It > is down (!!).

Meaning the entirety of RBX is down too. How can they have a single point of conection to the outside world? This seems like a bad joke, not a company running hundreds of thousands of servers...

Edit: and now nearly all of their fiber network is down too. Great.

> We have a general optical issue on all our optical network in Europe: all > chassis in all POP shutdown all the links 100G simultaneous (!!). RBX SBG > GRA LIM ERI are down. P19 WAW BHS are UP.

<comment><USER3> Update:

SBG: 2 routing rooms are UP powered by gen. EDRF still down. ETA: 15min RBX: the DB of the optical node in RBX is corrupted. All links are still down. We upload the backup. ETA: 30min

[https://twitter.com/olesovhcom/status/928552251458818048](https://twitter.com/olesovhcom/status/928552251458818048)

</comment></comment><comment><USER4> I were wondering, if they were finally hit by DDoS that would break the camel's VAC back.

Issues started around 06:15 UTC.</comment>


America's Biggest Charities Are Funneling Anonymous Millions to Hate Groups - <AUTHOR> https://readsludge.com/2019/02/19/americas-biggest-charities-are-funneling-millions-to-hate-groups-from-anonymous-donors/ <comment><USER2> If a group Pushes hate against a hate group, does it cancel out? Because Islam is the largest hate group on the planet.</comment>


Apple has a big big problem - <AUTHOR> http://kcbigring.tumblr.com/post/36449034986/apple-has-a-big-big-problem

<comment><USER2> What sustains Apple is innovation and design — As long as they have both I don't think the price point matters.

People want to be unique but they also want to be trendy. You're either hipster (want to be different), mainstream (want to be trendy and buy the iProducts) or in the middle (don't care what you buy as long as it's a tablet).

Apple gets in trouble when their product resembles a competing product. This is either because Apple stole ideas or the competing company stole ideas. It's not about who invents a specific feature first. What's important is who comes to the market first and whether the idea is just another feature or if it's innovative.

</comment><comment><USER3> The article relates that kids are essentially using whats in front of them. These kids are not yet brand aware and so they use whatever device has some shiny.

These kids however will become _very_ brand aware as they grow up (school is all about social status) and once they _are_ brand aware many do choose Apple because they're "cool".

Apple is only in trouble is those that _are_ brand aware start to pick differently, and there's no evidence to suggest that Apple has lost this market.

</comment><comment><USER4> I dont know age of your kids, I have 2 daughters 9 and 6 and their friends at school and neighbourhood have many different gadgets, which they share and talk about, and consistently my kids chose iPod, iPad and iPhone given a choice for apps, games, learning , My kids also have a PC as school curriculum is windows based .</comment>


6502 arithmetic and why it is terrible - <AUTHOR> http://cowlark.com/2018-02-27-6502-arithmetic/ <comment><USER2> The memory-inefficiency of the 6502 in doing 16 bit arithmetic lead Steve Wozniak to write a tiny virtual machine he called "sweet 16". That is a compact 16 register 16 bit arithmetic bytecode language implemented in about 300 bytes of 6502 machine code. It trades off speed vs memory, at about 10 times slower but 2 times more dense than straight 6502 machine code for 16 bit operations. And it is designed to easily jump back and forth between the sweet 16 bytecode and 6502 machine code. It might not be a bad fit for what the author is trying to do! [1] [http://www.6502.org/source/interpreters/sweet16.htm](http://www.6502.org/source/interpreters/sweet16.htm)

<comment><USER3> Wow! I had no idea he did this. I did something similar, but unlike Steve's interpreter, I used BRK instructions as prefixes to my pseudo-ops. This let me mix straight 6502 assembly with my pseudo-ops without switching between different modes. I wish I could find the code that I wrote for that ... probably in a printout in a box somewhere.

</comment></comment><comment><USER4> Ah 6502 arithmetic... Back in 1984 I wrote a 3D graphics toolkit for the VIC20 in 6502 assembler. Starting with fixed point multiply, then my own floating point format, then floating point arithmetic functions, including transcendentals. From there I added 3D to 2D perspective and orientation transforms. And finally Bressingham's line drawing algorithm, clipping, etc.

I was 14 at the time. Wrote the code in exercise books on a Christmas camping holiday and then typed it in when I got home. After a couple of weeks' debugging during the January summer school holidays, it all worked.

Kids nowadays don't know how easy they have it. Clone a Github repo... Pfffff !

<comment><USER5> So obviously this is impressive for a 14 year old in 1984. What were your sources of information? What was your line of learning? It's very interesting not only that you were able to do this, but the path that led you to being able to do it. 14 year olds don't just re-discover years of work in their heads.

Thank you!!

<comment><USER4> Good questions! I had two starting points:

a) I won the VIC20 as a prize in a science competition age 13. I started with BASIC, discovered PEEK and POKE, and then saved up my pocketmoney for the Assembly Language cartridge. I was intrigued by the ROM and copied the entire disassembly into exercise books to figure out how it worked (printers were too expensive back then!). I reverse engineered the arithmetic routines, from which I discovered floating point representation's mantissas and exponents.

b) I expect the graphics transformations came from Mathematical Elements for Computer Graphics, by David Rogers and James Adams (McGraw-Hill, 1976), which I would have found in the library at my mum's work. Her work was opposite my school and I often killed an hour or two in the computer section reading back issues of Byte magazine waiting for her to drive me home. I think that was the book because prompted by your question, I just found Rogers' 1988 update Procedural Elements for Computer Graphics in my bookshelf. The price sticker inside the cover says '1/89 $41.99'. That shows I bought it with the money earned from my first university holiday job in Dec 1988/Jan 1989. That was at the research labs of BHP Billiton, the Australian mining company, where I designed and built the electronics for a 32-channel channel data logger for a steel rolling mill, and taught myself C and wrote the data acquisition and display software.

</comment></comment></comment><comment><USER6> 6502 was from a different era. Not really designed to be a great compiler target.

Most other old 8-bitters have comparable issues.

One nitpick, decrement 16 bit value by one. From the article:

      4   ae a0 aa   ldx a+0
      2   ca         dex
      4   8e a0 aa   stx a+0
      2   e0 ff      cpx #ff
      2   d0 03      bne label
      6   ce a1 aa   dec a+1
                    .label
      (20 cycles maximum, 14 minimum, 14 bytes.)

It'd be better to do something like this, 11 bytes, (max 24/min 12 cycles, assuming article cycle counts are correct):

      4   ae a0 aa   ldx a+0
      2   d0 03      bne label
      6   ce a1 aa   dec a+1
                     .label
      6   ce a0 aa   dec a+0

4 more cycles for the worst case, but that occurs only every 256th time, in which time the best case has already saved cumulative 510 cycles compared to the article version.

On 6502 one should really keep the variables on the zero page. Same operation would take just 8 bytes for that case.

<comment><USER7> And you can extend the decrement for 32 bits as follows:

        lda a+0
        bne .3
        lda a+1
        bne .2
        lda a+2
        bne .1
        dec a+3
      .1:
       dec a+2
      .2:
       dec a+1
      .3:
       dec a+0

<comment><USER6> Pretty logical extension.

It still takes only 12 cycles if a+0 != 0. 24 cycles if also a+1 != 0 (=every 256th round), etc.

The worst case time is when whole 32-bit counter is zero, 12 clk * 3 + 6 clk = 42 clk.

(Disclaimer: clock counts assume original snippet counts were correct).

</comment></comment></comment><comment><USER8> Well, the 6502 is simply not made to be programmed in a high level language.

Note that there are many instructions that simply don't map to high level language features, such as bit rotation (not shift!), BCD mode and indirectly indexed adressing.

One thing that it very popular in highly optimized 6502 assembler code is self-manipulating code or even run-time generated code. This allows to work around a lot of limitations with indexed adressing or parameter loading.

The 6502 was designed at a time when CPUs were not limited by memory speed. I imagine that has only been the case right after the emergence of the first MOS-Memory (Intel, late 60ies)

Edit: For those interested in state of the art optimized 6502 arithmetic, this is a very good source:

[http://codebase64.org/doku.php?id=base:6502_6510_maths](http://codebase64.org/doku.php?id=base:6502_6510_maths)

<comment><USER9> This reminds me, why do most high-level languages lack a bit rotation operator?

It's an operation that is required in some cases, and it can easily be emulated by the compiler for targets which lack it. However deducing that you're trying to do bit rotation and emitting the CPU instruction when present is not easy for the compiler.

<comment><USER10> > However deducing that you're trying to do bit rotation and emitting the CPU > instruction when present is not easy for the compiler.

Uh, no. a rotate_left b is equivalent to a << b | a >>> (sizeof_in_bits(a) - b). As far as common instructions not present in language standards go, regular rotates are the _easiest_ for the compiler to recognize.

<comment><USER9> Well then, I've must have been using the wrong compilers, as they did not output the rol/ror instruction last I tried.

edit: For example, VS2017 x86 target does not output rol instruction for your code with /O1.

<comment><USER9> Ah, it does it with 32bit operands but not 8bit. That must be why I missed it.

<comment><USER6> Can you show your code for 8 bit case that fails to generate rol?

<comment><USER9> Seems I must have messed something up in the initial testing. Now it outputs rol with uint8_t too. Well, that's good to know.

For the record, here was what I was testing:

      #include <iostream>

      uint8_t rol(uint8_t x, uint8_t c) {
      	return (x << c | x >> (sizeof(x) * 8 - c));
      }

      int main()
      {
      	volatile uint8_t a = 0b01010000;
      	volatile uint8_t b = 3;

      	uint8_t c = rol(a, b);

      	std::cout << static_cast<unsigned int>(0b10000010) << std::endl;
      	std::cout << static_cast<unsigned int>(c) << std::endl;

      	return 0;
      }

</comment></comment></comment></comment></comment></comment></comment><comment> david-given Hello, author here.

Naturally I get my fifteen minutes of internet fame while I'm on holiday on the pilgrimage paths in Japan, so this is going to be pretty short, but yeah, there are some mistakes in the article (`cpx #0xff`... bah); please post comments and I'll fix them. Eventually.

There's also a followup article on doing exactly the same thing on the Z80: [http://cowlark.com/2018-03-18-z80-arithmetic/](http://cowlark.com/2018-03-18-z80-arithmetic/)

This was all in aid of writing the 6502 and Z80 backends for my self-hosted Ada-like programming language, Cowgol: [http://cowlark.com/cowgol/](http://cowlark.com/cowgol/) (Supports native compilation _on_ CP/M, Fuzix and BBC MOS, _for_ CP/M, Fuzix and BBC MOS!)

...and I put what I'd learned to work and have a program which will render Mandelbrots in under 13 seconds on a 2MHz 6502: [http://cowlark.com/2018-05-26-bogomandel/](http://cowlark.com/2018-05-26-bogomandel/) (Although I do need to point out that the key algorithm isn't mine!)

</comment><comment><USER11> This takes me back to the early 80s when "Personal Computer World" (UK) used to have a letters column called "Subset", where people would share short assembler routines for the 8 bit chips of the time. People would share optimisations, hidden opcodes, quirks about the chips etc. Often there'd be posts that shaved a byte or two or a few t-states off a previous months post. It's amazing how inventive people can be with limited resources.

It seems that as processors are so fast and memory so abundant now that squeezing the last drop of efficiency from a routine is a dying art.

[https://en.wikipedia.org/wiki/Personal_Computer_World](https://en.wikipedia.org/wiki/Personal_Computer_World)

Many of the Z80 and 6502 routines have been collected together into a couple of books, mentioned here:

[http://mycodehere.blogspot.com/2011/10/my-work-in- print-1985...](http://mycodehere.blogspot.com/2011/10/my-work-in- print-1985.html)

<comment><USER12> A dying art? Yes and no... There have been quite a few recent articles posted here about squeezing the maximum performance out of compression algorithms, say, by clever use of SIMD operations.

It's certainly less common now to be quite so concerned with shaving individual bytes off the code size. But I bet that still comes up when generating function prologues/epilogues/trampolines etc in compiler output -- stuff that will appear a _lot_ in the output, so even one word saved will be significant.

<comment><USER13> And I imagine the energy savings of such a change over billions of devices can be phenomenal in some cases. I'm glad there are still people working on these things.

I think it's true, though, that it's now a much narrower subset of people — it's not really desirable or practical for most hobbyists to dive deep into assembly, the way I remember seeing back in the '80s.

</comment></comment></comment><comment><USER14> > _This works. Don 't do it unless you really have to (and if you do, you > probably want to use a bytecode interpreter instead)._

Like, oh, Woz's "Sweet 16".

[https://en.wikipedia.org/wiki/SWEET16](https://en.wikipedia.org/wiki/SWEET16)

"The SWEET16 interpreter itself is located from $F689 to $F7FC in the Integer BASIC ROM." I.e. 371 bytes of code.

<comment><USER14> M - N + 1, darn it! 372.

</comment></comment><comment><USER15> _takes the 6502 ten to twenty bytes to do something which its closest rival, the Z80, could do in about five (and which an 8080 can do in two)._

What operation takes more code on a Z80 than an 8080? It's been a while since I worked with them, but I believe the Z80 was an enhancement of the 8080/8085.

Overall this is a good explanation of how very limited the 6502 is compared to something like a Z80, especially from the perspective of a compiler writer; it's really best programmed in Asm, where a human will be more easily able to apply some "lateral thinking" to reformulate problems in a way more conducive to implementation. Nonetheless, C compilers for the 6502 exist (and they are still common as IP cores in embedded systems) --- but the dialect of C they accept is very much non-standard.

 _What the helper function does is to pop the return address of the stack, copy the next six bytes into a parameter area, perform the computation (remember that the parameters here all point at the destination variables), and then push the updated return address back onto the stack._

That reminds me of how compilers for the 8051 (another 8-bit MCU that is not "HLL friendly") deal with pointers: it has several separate address spaces, so pointers can be up to 3 bytes long, and thus the necessary dereferencing is accomplished by calling library functions:

[http://www.keil.com/support/docs/1964.htm](http://www.keil.com/support/docs/1964.htm)

<comment><USER16> I'm pretty sure he's talking about doing 16-bit arithmetic with the 8-bit carrying or simply multiplying numbers since that requires adding multiple times. I mean this code here is the "fast" way of multiplying numbers:

[http://www.6502.org/source/integers/fastmult.htm](http://www.6502.org/source/integers/fastmult.htm)

</comment></comment><comment><USER17> > _I only have 64kB to play with, so it 's important to be efficient._

If the author does not want to upgrade to the 1980s and the 65816 with its 16-bit accumulator, there is always the KimKlone for relieving the memory pressure somewhat.

* [http://laughtonelectronics.com/Arcana/KimKlone/Kimklone_shor...](http://laughtonelectronics.com/Arcana/KimKlone/Kimklone_short_summary.html) ([https://news.ycombinator.com/item?id=16564257](https://news.ycombinator.com/item?id=16564257))

<comment><USER18> Thanks, JdeBP, for remembering the KK :-)

<comment><USER17> You might want to discuss whether any of your instructions or registers would make an interesting port of Sweet16.

* [https://news.ycombinator.com/item?id=17278022](https://news.ycombinator.com/item?id=17278022)

</comment></comment></comment><comment><USER19> I wonder if you could bootstrap a superoptimizer using the entire body of 6502 code written thus far.

<comment><USER20> It's in a very rough state, but I have been working on something similar. The idea is to build a superoptimizer by exhaustive enumeration of instruction sequences. In a first pass, each sequence is executed on some test machine states, and bucketed by the hash of the results. On the second pass, we use a theorem prover to check the equivalence of the sequences.

See: Automatic Generation of Peephole Superoptimizers, Sorav Bansal and Alex Aiken, ASPLOS 2006. [https://theory.stanford.edu/~aiken/publications/papers/asplo...](https://theory.stanford.edu/~aiken/publications/papers/asplos06.pdf)

My implementation: [https://github.com/RussellSprouts/6502-enumerator](https://github.com/RussellSprouts/6502-enumerator)

</comment></comment><comment><USER21> The 65c816 (1984) adds a 16-bit ALU. Also MUL and DIV instructions. Even if you don't use its 24-bit address bus (which sucks to wire up), it is a big improvement

According to Bill Mensch and Chuck Peddle the 6502 (and I guess the 6800 work it was originally based on before the team left Motorola) was really designed for industrial applications, not for general computing. Hence its ultra-fast interrupt handling latency and minimalist low-cost design.

Absolutely the Z80 had a richer instruction set. As did the 6809. But the 6502 was more cycle efficient than the Z80, and also cheaper. It did well in the simple games and graphics oriented machines of the late 70s early 80s for this reason.

<comment><USER22> 65c816 doesn't have multiplication or division. The SNES had multiplication/division support, as did at least one oddball 816 variant but stock 816s don't.

</comment></comment><comment><USER23> "The biggest problem is that multibyte arithmetic has to be processed in LSB to MSB order, with the carry propagating from one byte to the next; but on the 6502 it's so much easier to count down than it is to count up..."

Not that I've tried this (haven't programmed in 6502 assembly in 30+ years now) but doesn't that suggest he should order the bytes in the opposite direction? (ie, if I'm understanding correctly, he's using little-endian now but his comments make me wonder if big-endian might be more efficient on 6502.)

</comment><comment> nils-m-holm I wrote a FORTRAN IV (subset) compiler for the Apple ][ once. It used fixed- point arithmetic and the compiler output was subroutine threaded. E.g. a=b+c would translate to

      jsr load
      address of b
      jsr load
      address of c
      jsr add
      jsr store
      address of a

Like in the method described by the author, subroutines would fetch their arguments (if any) from the code and adjust the return address. I have no idea how fast it was, but it was certainly faster than doing the same computations in Applesoft BASIC.

<comment><USER5> I don't want to say I invented a FORTRAN variant, but I also wrote a stack- based arithmetic engine for gbcpu (similar to z80/8080 but NOT THE SAME). It was used like:

        ld hl, myNBitSizedVar
        push hl
        ld hl, myNBitSizedVar2
        push hl
        call addNBitSizedVar

Result returned is a pointer to the result in hl. This way I could chain many operations.

</comment></comment><comment><USER16> > Sadly, I can't use this trick for decrements. In this case, I need to > decrement the high byte when the low byte underflows from 0x00 to 0xff. > Sadly, the CPU doesn't let us check for this for free, so I need to load it > into a register and do an explicit comparison.

Can you check the ~overflow~ negative flag?

[http://www.obelisk.me.uk/6502/reference.html#DEC](http://www.obelisk.me.uk/6502/reference.html#DEC)

<comment><USER6> > Can you check the overflow flag?

Your link states overflow flag is not affected by DEC.

<comment><USER16> Sorry I meant the negative flag

<comment><USER24> Nah that would catch all negative results, not just 0xFF.

<comment><USER16> This got me thinking maybe it can be used for indexing from 0 - 128 for indexed addressing modes and that begs the question are the indexed addressing signed or unsigned? Apparently they are unsigned, so the trick might be possible:

[http://forum.6502.org/viewtopic.php?t=1300](http://forum.6502.org/viewtopic.php?t=1300)

</comment></comment></comment></comment></comment><comment><USER16> For fun I have been implementing a 6502 emulator in the last few days. It's a very strange platform in some regards but also the first assembler I learned (many years ago) so I'm confused at how I should feel. My goal has been to try to learn more z80 and x86 so I have something to compare it to.

</comment><comment><USER25> Saved, I'm planning on making a higher-level assembler that targets 6502, this would be massive help.</comment>


Role or company? - <AUTHOR>

Hi guys, long time listener, first time caller here. So my question boils down to this: what is better, a great position at a not-so-great company or a not-so-great position at a great company? I realize there's probably not a general answer to this so here are some more details in my case:<p>- Both A and B are high profile names in their respective domain and have a strong online presence (Alexa top-500 global traffic rank); A serves mostly static content, B mostly dynamic.<p>- Great position at company A: greenfield project, potentially high visibility, small agile team, significant autonomy to choose and build the whole stack.<p>- Not-so-great company A: Primarily a media company, software is just a tool. High level decisions are taken by journalists and suits, often not the most internet and tech savvy individuals. Poor, unstable management (requirements changed drastically midway, we had to dump more than half of the code written up to that point...). With a few exceptions, the overall tech level is mediocre (e.g. ad-hoc version control).<p>- Great company B: Built from the ground up as a software company; follows latest technologies and best practices. Challenging, stimulating environment.<p>- Not-so-great position at company B: Ok that's a bit subjective but I mean something less "sexy" that a lead developer tackling huge scalability problems and playing with the latest toys. Think of non public facing roles, e.g. internal apps, tools support, automated testing, etc.<p>For the sake of discussion, the question implies "all else being equal"; i.e. location, salary, perks, vacation days, double screen monitors, playroom and whatnot are assumed to be comparable or unimportant. <comment><USER2> Company B. Roles change all the time. Especially if you work hard to make sure they change. Great companies are hard to come by.</comment>


YC Summer 24 Interview - <AUTHOR>

Have you heard back yet? It's 7:20 PM PST and we still haven't heard any news. <comment><USER2> Waiting on tenterhooks! It is really nice they send out both yeses and no's

</comment><comment><USER3> Just received the response. We couldn't make it. Best of luck to you guys.

<comment><AUTHOR> yeah same :( best of luck to you too

</comment></comment><comment><USER4> It's great they will take the time to respond with both Yes and No

</comment><comment><USER5> I think they said 10pm PST. So a few more hours.

<comment><AUTHOR> where did you see that?

<comment><USER6> [http://blog.samaltman.com/the-worst-part-of- yc](http://blog.samaltman.com/the-worst-part-of-yc)

</comment></comment></comment><comment><USER7> They're working hard - the time will come.

</comment><comment><USER8> Yep haven't heard anything yet

</comment><comment><USER3> will they be contacting us via email or what?

</comment><comment><USER9> Nothing yet</comment>


Google Blames Human for Robot Car Crash - <AUTHOR> http://nbcbayarea.com/blogs/press-here/Google-Blames-Human-for-Robot-Car-Crash-126845683.html

<comment><USER2> The same story from many sources:

<http://news.ycombinator.com/item?id=2851277>

<http://news.ycombinator.com/item?id=2851408>

<http://news.ycombinator.com/item?id=2852393> : A few comments

<http://news.ycombinator.com/item?id=2853758>

<http://news.ycombinator.com/item?id=2853970> : A few comments</comment>


Five Cheap Ways Tech Is Transforming Classrooms - <AUTHOR> https://medium.com/bright/five-cheap-ways-tech-is-transforming-classrooms-3f0530f0c1b0

<comment><AUTHOR> Love the creativity of teachers. The microscope is all kinds of amazing.</comment>