skysight-inc/HackerNews huggingface dataset:
> Why would one choose erlang/elixir over akka

- BEAM has green-thread-local GC.

- As you mentioned, preemptive scheduling is implemented at the VM-level and is relatively elegant.

- Faster startup times (meh)

- Dynamic typing (subjective)

> JVM is generally more efficient

Depends on the scenario (and JVM implementation) - tracing, STW GC isn't always the best option.

> has better tooling (ide support)

Yes.

> has better libraries

Bit subjective, but there are certainly MORE JVM-compatible libraries.

---

Personally not a fan of Akka simply due to the underlying languages commonly used with it (Scala, Akka)

As a Haskell-user: if forced to choose between Scala and Elixir, I would choose Elixir.
You mean that out of all the things in this combinator [0] flavored abstract rewrite system [1], programmed via a symmetrical [2], forward-inferenced [3] typed language, exposing modula-2 style per-code-block compilation control [4], all designed to support a content centric [5], natively networked [6] global computing environment with sovereignty-hard siloing capabilities [7],
the most difficult part to understand is the naming scheme?

Edit: In the early Urbit docs [8] there was a nigh ad nauseam emphasis on the "stupidity" of the project. What the epiphany of careful inspection revealed was that this stupidity was not that of intellectual deficiency, but rather opposition to "cleverness" of the kind that tends to foster (and infest) Urbit's peer group of deep stack [9] rebuilds. One of the most insightful comments I've heard after springing Urbit on unsuspecting PL professionals was (paraphrased): "It [Urbit] does all the things we've said we wanted, in the worst possible way." All words are equally made up until grounded in referents. The question is, are the Worfian shorthands new words provide worth the cost [10] of expanding the symbol table, as compared to the interpretation overhead of translating new concepts into old? Under the burden of internalizing all the content linked below and more, I judge new vocabulary justified.

[0] http://www.ucombinator.org/

[1] https://en.wikipedia.org/wiki/Abstract_rewriting_system (ARS being the most mechanical of the pure computational models outside reversible logic)

[2] http://tunes.org/wiki/symmetric_20lisp.html

[3] https://en.wikipedia.org/wiki/Forward_chaining

[4] https://en.wikipedia.org/wiki/Modula-2#Description (see Definition/Implementation modules)

[5] https://en.wikipedia.org/wiki/Content_centric_networking

[6] http://netcentriccomputing.org/

[7] https://en.wikipedia.org/wiki/Capability-based_security (not yet fully implemented)

[8] http://moronlab.blogspot.com/2010/01/moron-lab-goals-princip...

[9] I won't say full stack, because the reshaping blade only penetrates OS deep. For a hardware-grounded reset, see good old Loper OS (http://www.loper-os.org/?p=8).

[10] Because words are context dependent, this expansion is only logarithmic with respect to the increase of immediately referable concept space.
I saw this https://news.ycombinator.com/item?id=2909881
The feature was recently delayed, but it should help once it's ready
What is off the table, exactly? You asked why you would extract a deb instead of extracting a tarball or curl|bash, right?

Because the deb is verifiable, because the deb can be inspected, because the deb is versioned, because the deb can be bug-reported, because the deb has dependency info, because you know what the deb was built for and supports, because the deb has clear scripts which tell you how to install and uninstall it, because it can be unpacked offline, etc.

Maybe you don't care about any of this. That is fine. I'm just telling you what the Deb gives you that a tarball or curl|bash won't.
(Another post about React Native)

Facebook engineers keep telling everyone that React Native is not used in the main Facebook app. I always wondered what is stopping them from start using it. Perhaps app size is a massive concern? Maybe all this tooling around their app is not really compatible with React Native?

Its interesting that they have a ton of legacy Obj-c code (considering that companies started to build apps not very long time ago, and they already re-wrote their app several times) I wonder if any other company is a situation like this well other than Apple.
Brilliant. Zulip has been a life-changing tool for us: it's the key technology supporting a change in social environment that lets us employ remote staff and collaborate effectively.
I have to disagree with your nitpick. The presentation basically depicts spike timing dependent plasticity (STDP). STDP has been shown to occur in many brain regions and species, including mammals. It may not be the only learning rule that the brain uses, it's clearly an important and widely used one.

http://www.scholarpedia.org/article/Spike-timing_dependent_p...
Is this one of those "we'd like to buy your domain" outfits that buys domains with some traffic and fills them with ads?
Their needs are because they're sloppy. Having an overarching Core team who's job is to maintain the app and guide the architecture would cut down on what they need immensely.
The truth of this post strongly depends on both where you live, and who you work for.

If you live in New York, what this post says is absolutely true. Anything you do, on your own time, on your own equipment, belongs to your employer. And it sucks. I believe that this is a hidden drag on startups there. And it is one of the reasons why I do not want to live in New York any more.

If you live in California, this post is mostly wrong on IP ownership. The exception is that if you're doing something that relates to your employer's business, then you've got a problem. Even if you didn't know it related. Which is a problem if your employer has a lot of irons in a lot of fires like Google, Amazon, Yahoo, and so on do. However it isn't a problem if you work for a small company.
Thank you. Am i the only one still on a desktop? I can't stand shit video players with no progress bar and no volume control.
Mastercard calls it the "Automatic Billing Updater" [1].

For non-fraud related reissues, it's not a flaw but actually an enhancement: you don't have to remember to update your card information whenever your card expires.

[1] http://www.mastercard.com/us/merchant/pdf/MasterCard_Automat...
I've been thinking a bunch about why it's the trivial projects (Altair, the WWW, Facebook, Twitter, Reddit, AirBnB) that change the world, and the change-the-world projects (Xanadu, WebTV, Chandler, WebVan) end up becoming trivial.

I think it's because of a quirk of human psychology. The value of a product to us, as a user, is about how well it fits into our daily lives. "Fits into" is the operative phrase: to get adopted, a product needs to be nearly invisible, and fit into what we're already doing so well that it's just a seamless augmentation of our own capabilities. Such products naturally seem trivial.

By contrast, we judge the importance of a project by a combination of a.) how difficult it was to do and b.) how many people it affects. Both of these are anticorrelated with how likely it is to fit into our lives. Difficult projects are usually complex; that complexity tends to spill over into the user interface and make it harder for us to make sense of how we would use the product. (Indeed, when moonshots like Google or Tesla succeed, it's usually because they manage to put a complex problem behind a really simple & familiar interface.) And aiming to please a large audience means handling a lot of corner cases, which again bloats the user interface and makes it harder for any one person to adopt it.

Once you've got lots of happy people adopting the product, they can serve as teachers and evangelists to bring a little more complexity to the wider world. But if you build something designed to change the world from the start, it tends to "bounce off" of the world, as it doesn't actually fit into the daily needs of any one person.
MUST WATCH 'AMAZING AIRPORTS IN THE WORLD'
No the bash script doesn't verify itself. The only real verification step is using https (and writing the script so that it's not vulnerable to truncation attacks).
Your product reverts back to the version you've fully paid for via subscription.
Time to have another bash I think. She might take to a G4 Mac Mini over a full sized G5 as well ;-)
I have the same feelings about Rust.

It's the light at the end of the tunnel for a native language with a great type system and decent primitives.

Something as low-level as Rust can't deviate as far as, say, Haskell, from the procedural, register-machine reality in which we operate, and that's fine.
There was no major leap. Have you ever heard of the Antikythera Mechanism [1]? A small device built two thousand years ago to predict astronomical positions. As a counter argument it shouldn’t have taken us two millennia to reach the first computer. Science should have progressed a lot faster, there was no shortage of intellect. There was a shortage in political support of science though, especially if you put in the mix the strong opposition of religion which used to have a huge influence in how things were run a few centuries ago. Once that influence withered science flourished.

[1] https://en.wikipedia.org/wiki/Antikythera_mechanism
There are definite bad ways. I've watched a few companies go down the shitter using known bad ways.
They'll likely have security cameras to prevent vandalism on the inside of the vehicle. I doubt most people want to be recorded having sex and have it watched by strangers when an "issue" is reported.
1. Having a core team who's job it is to maintain the app and clean up the debt.

2. I seriously have to question that they absolutely need that pace. I don't buy it for a second that any of this is necessary or better than the alternative.
>It's all a bunch of bored engineers looking for ways to be clever but without anyone to take ownership of the codebase.

You couldn't think of a more charitable interpretation? I'm not one to care about rules but the hn guidelines on commenting are important for making sure the community doesn't eat itself alive like reddit did/does.

>The app itself doesn't do that much.

Right, but in the presentation he made it clear that it was less about what the app does and more about the number of engineers making changes to it. Given the size of their teams all making their own changes to the iOS codebase, doesn't it make sense to modularize it so they aren't tripping over each other breaking the application constantly? They don't have a dedicated iOS team and having one would bottleneck the other teams.
There's a checksum for each package and for the CD. Back in the day, people cared about that.
On the install page for every PPA is a 1-3 line snippet you can copy and paste which will do add-apt-repository and apt-get. It's not hard and it sounds, from reading all the pro homebrew/linuxbrew comments around here, that this is more of a case that people want to reinvent something that's not broken, and are determined to do so without learning any of the lessons from the last 30 years of package management.

But hey, it prints out an emoji beer mug, so that's cool right?
Re: AVID vs CAP.

You're right about the C(onsistency) bit, but the A in ACID stands for Atomic, not Available.
No. They mostly broker transactions of people whose businesses resemble "A website with X0k monthly uniques acquired through organic SEO which is presently monetized by reviews of various products on Amazon which get the Amazon affiliate program if someone buys that or any other product consequent to clicking their link; revenues for the last 6 months averaged $1,700 on expenses of $300, dominated by outsourced content writing." (That's a point along the spectrum, probably close to their modal listing in sophistication and possibly under their median; I don't follow closely enough to have a great sense of that.)

Some people have businesses like this which for whatever reason they want to sell; other people have money which for whatever reason they prefer less than having business like this [+]. Empire Flippers operates a brokerage which matches these people together, for a cut of the transactional price.

(I listen to their podcast, which is really good, even if one's business does not resemble the above.)

[+] One of the most interesting recurring themes on their podcast is a series of user avatars for who would be interested in this -- Porfolio Paul (wants to have 10+ businesses like this and operate them like someone operates a number of fast-food franchises) and Lifestyle Larry (wants to be the owner of a business which makes $X0k a year in preference to having a day job) are two who stick out for me.
Reference Imports in LESS
Also, the three-letter variable names aren't part of Hoon -- they're just a convention that works well if (and only if) you have short, simple functions.

I've actually taken to using TLVs with a Hungarian suffix in C -- it works well if (and only if) you have short, simple functions.

One way to think about variable names: declaring a variable is a way of saying "I couldn't quite get this into point-free form." Names should be the exception, not the rule. Again, this is much more true in a functional language.
Dropbox has open-sourced Zulip
That exists in the US as well.
Chrome plug-ins have a lot of control over network requests through the webRequest API[1]. They're easy to write - email me if you have questions.

[1] https://developer.chrome.com/extensions/webRequest

"Use the chrome.webRequest API to observe and analyze traffic and to intercept, block, or modify requests in-flight"
Nobody is using App Transport Security; what’s next?
> being different for the sake of being different

Urbit has brilliant technical insight into perhaps the hardest problem our industry currently faces: why does everything always turn into a big ball of mud?

Urbit may turn out to be incredibly important. Parent comment is unjustified, uninformed, poor tone and ad hominem.
Thanks for posting! Great to hear him talking about this.
It's not so much the readers we need to be concerned about here, but the evaluators.
Confessions of a bad software entrepreneur
I trust an expert in cross-domain over an expert on encryption any day. Having done cross-domain design, I know you have to look at the system holistically from the hardware up and at every interface (eg protocol). Most flaws in crypto are implementation and protocol issues. So you want someone whose regularly coding and hacking systems to build that rather than people looking at math all day. He can hire a real cryptographer to review and improve his algorithms as his business brings in revenue. Implementation and interfaces, though, are where risks are and his strength.

The key escrow bothers me, too, though. It requires key escrow without a HSM (far as I know) and under U.S. jurisdiction. Plus, a high assurance system resistant to nation-states is time-consuming to put together. Their development speed, client support, and price indicate they're using a low assurance process with mainstream components. So, their escrow is at risk to both a court order and hackers. Not to mention malicious insiders.

I'll pass...
> Note that "package-the-world-and-freeze" distributions (Debian, RHEL, whoever else) have an entire infrastructure in place to creating their own line of packages from an "upstream's" basic-tarball releases.

> When Debian determines to, e.g., support Linux 3.6 for the next five years, it's not suddenly Linus's responsibility to backport kernel patches to Linux 3.6. Likewise, it's not your responsibility to maintain a stable branch of your software so that Debian can do less work packaging it.

That's great and all, but if I'm a Ruby dev my life isn't any better just because the burden of packaging a 4-year-out-of-date version of the runtime isn't on me. The Rails community wants to move to the latest Rails version, which wants to user modern Ruby syntax, which depends on a modern Ruby version, and the community doesn't just want to bifurcate and fork every single gem for half a decade because Debian's dragging it's feet about the next release. And I can't just order my users to use Debian Sid in a production environment.

The fundamental problem here is that Distro-packaging is optimized to distribute software for an ecosystem comprised of that Distro's users. The problem a lot of dev tool projects run into is that they serve a cross-cutting community of many different OS's users, all of whom want to stay in sync with the rest of the cross-cutting community, and who couldn't give two shits about what some other person's OS's package repo's timelines are like.

That's the niche that NPM, RVM, et al are serving and it's a niche that distro packages are completely unsuited to handle. And RVM et al tend to "package" as scripts because we're right back in this mess if Debian RVM users are 4 years behind OS X RVM users.
Well, this post was specifically complaining about working for large tech companies. I mean, it is right there in the headline of the post.
When both succeed, certainly. :-) We certainly don't try to solve the CDN problem that IPFS is solving.
I think they can, but a lot of it comes down to your willingness to play "the game". An example of what "the game" can look like is illustrated in this email we received from In-Q-Tel:

Hi Phillip,

I am with the investment team at In-Q-Tel
(www.iqt.org), which is the strategic
investing arm of the CIA and other US
intelligence agencies. We invest in
innovative companies that are building
cutting edge commercial technologies that
may enable the agencies we work with to
rapidly develop and deploy new capabilities.
In addition to investing, we also in almost
all cases purchase some amount of product
and services from these companies.
Our customer agencies then frequently
make follow on purchases directly
with the companies.

I recently came across some news
coverage of your company. I am contacting
you because your social collaboration
technology might be of interest to the
agencies we work with. Would you be
interested in having an exploratory conversation?

Please let me know if you have some
time over the next couple of weeks to talk further.

So in this particular case, I think the implications are pretty clear - "take money from us, and become a puppet of the military-industrial-defense-espionage complex (MIDEC), and we'll help make sure the MIDEC buys lots of your product".

Possibly a good deal for people who are into that sort of thing, but we chose not to pursue it, as I don't have any interest in supporting the CIA/NSA/DIA/DHS/FBI/ETC.
There are different classes of employee.

Your attitude is appropriate if you clock in, clock out, and are paid different amounts in different weeks if you show up for different lengths of time.

However I'm guessing that you are paid a fixed salary and aren't clocked. And you aren't a contractor. In that case you're a professional employee. You legally have a working relationship with them 24x7. Which is why you're not paid overtime to take clients out to dinner, or answer a page in the middle of the night.

But if that relationship always exists, who owns the intellectual property that you create away from the office? This is up to a combination of the contract you signed, and local laws.
The EPA screwed up by opposing DMCA rules that could've exposed VW
DNSSEC, TLS DANE is the proper solution for this.
I don't think any of our decisions are driven by or dependent upon the caliber of our engineers.

For example:

a) No merges; and the only branches are release branches. This makes sense in almost any context. Whether your team is big or small, high-caliber or college sophomores, this works. The advantages are numerous. No one works on a feature branch in isolation, only to have tons of merge conflicts and surprises when they try to bring it back in. Bug fixes and features are never landed on a release branch and then not merged into master for the next release. Development doesn't slow to a crawl while you try to stabilize master for a release.

b) Keeping dependencies near tip-of-tree. Chromium has two kinds of dependencies: third-party libraries (e.g. yasm, lighttpd) and things we develop on our own but in separate repositories (e.g. pdfium, v8, boringssl). The former tend to have stable releases produced by their own maintainers; the latter is being developed in parallel and you want to be as up-to-date as possible. Most projects are similar: you have third-party dependencies (e.g. python packages) and your own libraries (like a common set of api interfaces). You want to keep the ones you control as close to tip-of-tree as possible so that you can move fast and integrate your own changes quickly.

The caveat to all of this "move quickly" stuff is "test Test TEST". If you are constantly rolling dependencies forward, stuff will break. Run all the tests before landing a dependency change. Revert dependency changes with impunity: since they are effectively merges of many commits made to the other repo, they are more likely to have breaking changes than any single commit to your main repo. So pretest, test, and revert.

None of this requires amazing engineers. It just requires a dedication to quality and good testing hygiene.
My pay stub helpfully lists my 'pay rate', that number * 40 * 52 = my salary. If my employer expects me to work 168 hrs/week then I'd certainly be willing to have that conversation but I expect the appropriate change of multiplier :)
Volkswagen's Scandal Is Libor on Wheels
I always thought that when they revealed it they should have published photos of empty sky, saying "Look! There it goes!"
I wasn't talking out of my ass. Maybe my information is little dated - but from talking to actual legal teams at Turner & Warner Bros., this is what I was told.

Admittedly it was 2 years ago when I last talked to them - but given that it took you 8+2 years to finally get rid of DRM, there is some truth to what I was saying. It'd be helpful if you actually provided some counter reasons as to why content producers are actually holding onto DRM, and enlightening the rest of us, especially the poster who asked the question, rather than just saying "You're wrong because I spent 10 years in the industry".
Ok, we changed the title and the URL from http://www.kb.cert.org/vuls/id/804060 to the original source which it points to.
Could not find the interview video, but this was another one I remembered have watched:

https://channel9.msdn.com/Events/Visual-Studio/Launch-2013/V...

Starting at 00:18:40, note the "not an intent to conform to C99/C11".

FFMpeg was one of the customers
> Scheme is a Lisp.

No, it isn't.

> I've never met anyone who disagrees.

Now you have.
Engineers base their local development branches on top of origin/master. They can make as many local commits on that branch as they like. Then they upload the diff of that entire branch vs. its upstream (origin/master, unless they're doing chained changes) to the code review system. As it goes through code review, it is tested on the trybots. Once all the trybots pass and it has received approval from the reviewers, it is landed on master and fully tested again.
One of them was FFMpeg, from the video I digged out.
"choice for power users" is quite the claim, i dont buy it. its a choice, not THE choice.
DevTalk – Slack chat for any kind of developer
>I see a lot of people posting things to the effect of "It's probably not a huge deal, just a firmware patch."

Yeah if it were just a firmware patch VW would not have set aside billions to deal with the fallout and had the CEO resign.