carussell

After the leader of a substantial project disappears, in the ~20 minutes of incidental contact you have with the issue after having only just been introduced to it having not stumbled over a particular discussion out of sheer dumb fucking luck, you conclude that means the discussion never occurred. Do you really think that's a sound conclusion?

Let me put it this way, do you really think that, in the three months since this person disappeared, out of the dozens of people who have a far closer relationship to him than you do and a far greater personal stake in his wellbeing, that you are really the first person to consider whether something might have happened—to the point that you're comfortable to grandstand with a public indictment about how "sad" their behavior is?

You are the worst kind of person. Fuck you.

Did you fabricate a quote? (And if so, why?) Neither "innovation" nor any derivatives of "innovate" appear in this post.

That's a strong claim. What led you to conclude that nobody asked any of those things?

What's with all the legal bluster in your comments here? Not only do the liabilities you're trying to conjure up not exist, but this is not even the first occurrence of something like this happening with GitHub. They have a documented policy for freeing up inactive names. (Spoiler alert: it's allowed, and they've done it.)

> I believe Clang et al are fast enough.

This is a genuine case of survivorship bias in action.

I guarantee you that there are people not using Clang or writing, let's say, C++ because of slow compile times. You just never hear about how much they hate using them, because those people no longer are using them.

From Yegge's "The Pinocchio Problem":

> Great systems also have advice. There's no universally accepted name for this feature. Sometimes it's called hooks, or filters, or aspect-oriented programming. As far as I know, Lisp had it first, and it's called advice in Lisp. Advice is a mini-framework that provides before, around, and after hooks by which you can programmatically modify the behavior of some action or function call in the system. Not all advice systems are created equal. The more scope that is given to an advice system — that is, the more reach it has in the system it's advising — the more powerful the parent system will be.

https://en.wikipedia.org/wiki/Advice_(programming)

A "Have you considered..." question asks for a "yes" or "no".

A "Why[...]" question asks for why.

Assuming that "Why didn't you just do X?" isn't really just a disingenuous way to say, "you're an idiot; do it this way instead", then you should ask for what you want and ask the why question, not the yes-or-no question. In the case that it is a disingenuous question, then that's something that's covered adequately by #5. Suggesting the avoidance of sarcasm is already broadly applicable enough to cover using questions when you really mean to make a statement. (Which is not specific to code reviews—it's as obnoxious in real life.)

Do you actually know this, or like most commenters here, was your introduction to this case the Washington Post that everyone else read?

You could do secret splitting:

http://www.moserware.com/2011/11/life-death-and-splitting-se...

It's vulnerable in that whichever threshold N that you choose allows for N participants to conspire to publish ahead of time, or M - N to conspire not to publish after the fact.

The first link[1] in that post (for "searchable database") is a 404.

1. https://opentimestamps.org/internet-archive/

How does the Glitch project-to-app mapping actually work? This is writt.glitch.me, so I'd expect it to be accessible at https://glitch.com/~writt and https://glitch.com/edit/#!/writt except neither of those are up.

Specifically? I don't think there were specifics. Just the familiar general anti-JS sentiment.

I spent a few seconds looking through my feed of past Planet Gnome posts. It looks like the first announcement was here in 2013:

http://treitter.livejournal.com/14871.html

You can get a taste from the comments there. Here's some meta-commentary:

https://www.reddit.com/r/javascript/comments/17w0z5/javascri...

IIRC, it didn't really let up. I don't have a reference, but I vaguely recall something that, if not an official recantation, was akin to the general sentiment of backpeddling from the original stance, although I may be misremembering. In any case, the forthcoming concerted effort to go all-in on JS-for-Gnome didn't really happen as that post suggests it would.

A couple months after the fomentatious announcement linked above, GitHub quietly started work on Atom Shell and then a year later released Atom and Electron under MIT. What a massive lost opportunity for the Gnome folks to take advantage of the lead they'd set up for themselves instead of bowing to the vocal pressure! Had that not been the case, GTK+JS might've been the go-to framework for rapid cross-platform desktop app development in the instances where people are reaching for Electron today. (And that recurring plea for more "native" UIs would never be heard—or at the very least there'd be a straightforward path to migrate codebases to native in a piecemeal fashion if there was any motivation to do so.)

Looks like this thing is derived from the work by Kinoma[1], who has/had a $25 micro with networking. The link to their retailer is dead, though.

1. http://kinoma.com/buy/

GTK already has JS bindings. If you're running Gnome, then substantial parts of what you're seeing and interacting with on your desktop is JS.

The Gnome folks tried anointing JS as the de jure development language across the Gnome project (i.e., for apps, too) a few years back, but there was a minor backlash. Unfortunately, Electron came along within the next year or so has since snagged most of the mindshare that was up for grabs after they backpeddled a bit. You can write JS apps, but it's not a prominent park of the environment outside of Gnome Shell and extensions, AFAIK. The documentation is pretty lacking.

GJS is SpiderMonkey under the hood—the same JS engine used in Firefox. It would be interesting to see if XS were an improvement for Gnome. Web browsers are subject to constraints that aren't necessarily a relevant factor for static packages downloaded from your distro vendor. For example, it looks like XS/Kinoma/Moddable supports AOT compilation, which could be a win.

Metrics here look like they focus on RAM and not on speed of computation.

On the softer side, GTK folks do favor C, and the explicit endorsement of (L)GPLv3 is worth brownie points in that circle. (SpiderMonkey is written in C++, and MPL2 is compatible with (L)GPL, but its copyleft is weaker and allows more permissive use.)

In any case, this project is really neat. I only wish I'd heard about it back in 2015.

(2016)

Previously discussed here on HN back then:

https://news.ycombinator.com/item?id=12768425

The author has made some minor revisions since then. Here are the main differences to the page compared to when it was first discussed here:

http://web.cvs.savannah.nongnu.org/viewvc/lzip/lzip/xz_inade...

And here's the full page history:

http://web.cvs.savannah.nongnu.org/viewvc/lzip/lzip/xz_inade...

That's people doing margins wrong. They see a CSS property called 'margin' and go for that, which ends up only working well for displays and window sizes comparable to their own. What they should be using 'margin' for is to specify the minimum outer padding and combine it with 'max-width' to allow the browser to apply flexible margins appropriate for whatever window size the reader actually has.

The projects emerging to build a P2P Web bring an additional non-monetary reward system to this, which is that in return for publishing good content, you get readers/viewers who are willing to help offload server costs.

The naive implementation might work by simply reseeding, say, the Wikipedia articles you've already got in your browser cache to whomever is also interested in them.

There are also UI concepts, however, to give you fine control over how much and how long you're willing to help seed. (Like [1].)

The latter might end up being the currency of low-friction microtransactions that actually stands a chance of taking off. The downsides here are that it only helps in offsetting distribution costs, but it's not good for turning a profit (i.e., funding the creator's real life living situation). It might be fruitful to create a more fungible currency on these principles, though.

1. https://twitter.com/taravancil/status/983361106461720576

1. The ReactOS project's implementation of Windows APIs is purely for compatibility reasons; on the other hand, Android's implementation was not meant as a compatibility layer for existing apps. (In fact, that Android didn't implement a compatibility layer was a huge sticking point for the Sun contingent within Oracle—although if we're honest, we know the motivations for Oracle proper are the dollar signs.) It wouldn't be a good idea to try and draw direct parallels between the two.

2. Oracle v Google still isn't over, so even drawing any inferences about Oracle v Google itself would be premature.

3. The copyright holder here is MS. Any action on their part to go after ReactOS now be the undoing of all the goodwill they've built in the Nadella/MS-on-GitHub era. The result would be (a) a bunch of I-told-you-sos from the leery folks still holding on to their grudges today, and (b) a massive, massive, innoculating "fool me once…" reaction among the folks who'd actually been made suckers for not heeding the grudgeholders' warnings. All in all, it would be a spectacularly bad idea for MS at this point, especially given how much weaker their empire has already gotten in the last decade.

So you've decided to double down on the not-knowing-what-you're-talking-about thing? It would have taken you less time to look up the relevant facts than typing out that comment. Besides that, the whole thing reeks of post-hoc argumentation. This will be my last comment in this thread.

Literally untrue. If the facts aren't on your side, or you don't know them well enough to know whether they are or not, why even comment?

It's possible (likely, even) that experience of using GitHub is the exact reason why someone has decided not to settle there. Keep in mind that the Linux kernel—the very project that Git owes its existence to—is itself developed by a group that has eschewed with GitHub almost entirely for collaboration.

That, and the fact that GitHub is a closed source backend under control of a corporation that's accountable to no one.

For anyone in the Northern District of California at least, that's a pretty awful use case, for the reasons I mention above. You open yourself up to being culpable for the strongest hypothetical against you (versus just dealing with the magnitude of the worst thing that you actually did).

In fact, it can lead to worse outcomes than if you simply did nothing. In Apple v Samsung, the judge instructed the jury to assume that relevant evidence was destroyed and that said evidence would have been "favorable to Apple"—as a direct consequence of Samsung's email system, which as a rule only kept messages for 14 days.

https://www.nutter.com/pp/publication-Apple-v-Samsung-Electr...

https://www.lexology.com/library/detail.aspx?g=30282c16-31e3... (HTML version)

Hashbase exists, and in theory most Dat web apps could do a read-only version for legacy browsers, but since the tooling isn't there, you'd have to work out something by hand. The Dat ecosystem has pretty bad support for polyfills and bridging to the HTTP web right now. Many Dat demos I see today just fail hard over HTTP, maybe with a best-viewed-in message if the dev took some effort, but in principle it doesn't need to be that way.

> in practice it creates a barrier to adoption and makes the social network kinda useless

The main thing is that you're trying to bootstrap new cultural norms. If there weren't so much inertia around free services, people would probably be fine paying a few bucks per month for certain classes of services.

I've always thought it would be a great idea to fund message boards, communities, etc., by keeping track of users' individual resource usage and making that info visible to them.

GitHub is free for most, for example, and others pay for some extra perks. But even then, the price structure comes off as pretty arbitrary.

Since Patreon became a thing, I've seen some people set up funding goals that take the form of explaining that it takes, say, ~$85 per month to cover the costs of running servers, but that doesn't really accomplish what I'm talking about, since it's still too easy to treat it as a shared commons.

A running sum is able to make the point unambiguously; it says something along the lines of, "because of the requests we had to handle to serve your use of the site, we are now on the hook for paying $2.74 so far this month". If you're a magnanimous admin, you can continue operating free services, but just "soft bill" people with a pay-what-you-want scheme (by which I mean guilt them). If you're actually trying to cover costs you do hard billing, but offer the first year free or something, which also removes one of the barriers of getting started—so long as we're operating on the assumption that we've already managed to establish it as a new cultural norm.

Resource-proportionate billing also has the nice side benefit of getting people to be more conscious of wasting time on the site—breaking the cycle of idly refreshing the home page to procrastinate.

"Why Pascal is Not My Favorite Programming Language" is an article by Brian Kernighan. Kernighan didn't create C. Dennis Ritchie did. And between Ken Thompson, Kernighan, and Ritchie, Kernighan had the least to do with the creation of C.

What Kernighan did do is write the book on C. (You might argue that it's a conflict of interest, too, but it's not. It makes a lot of sense that someone would like a programming language so much that they'd decide to write a book on it.)

See, you're trying to foist a position on me that isn't mine—that I'm scared of the essential necessities of source control. And you act as if source control were invented with Git. Neither of these are true.

> git/hg

Mercurial was a great solution to the same problem that Git set out to tackle, virtually free of Git's foibles. The tradeoff was a few minor foibles of its own, but a much better tool. It's a fucking shame that Git managed to suck all the air out of the room, and we're left with a far, far worse industry standard.

You're minimizing the overhead. `git commit -a` also won't help you with new or renamed files. So when you write about "the overhead of typing -a", what you really mean is the overhead of

1. typing `git commit`, checking the output, then typing `git commit -a`, or

2. typing `git commit`, then moving on with your life, and realizing minutes, hours, or days later that the changes you meant to include were not actually included, so you have to go back and add them if you're lucky, untangle them from whatever subsequent changes you were trying to make and/or do an interactive rebase if you're unlucky, and maybe face the prospect of doing a `git push --force` if you're really unlucky

Scale that up to several days or weeks to match the learning period and repeat for every developer who has to sit down and interact with it. That's the overhead we're talking about.

The article got it right; this is a monumental waste of human effort.

> Every developer has a finite number of brain-cycles

Sure, and a piece table is a simple way to represent a file's contents. But if anyone wrote a shell or a text editor that required you to directly interact with the piece table to edit a file—instead of something sane—then they'd rightfully be called out on it. It wouldn't matter how much you argued about how simple the piece table is to understand, and it wouldn't matter how right you were about how simple the piece table is to understand. It's the wrong level of abstraction to expose in the UI.

This workflow can be yours, in 10 easy* payments:

  $ git stash
  $ git checkout stash@{0} -- ./
  $ $EDITOR # pare your changes down
  $ make runtests # let's assume they pass
  $ git add ./
  $ git commit
  $ git checkout stash@{0} -- ./
  $ make runtests # let's assume they pass
  $ git add ./
  $ git commit

*(In case it appears otherwise, this isn't actually supposed to be a defense of Git. Originally, this was 15 steps, but I edited it into something briefer and more straightforward.)