What changed in OpenSSL after heartbleed - <AUTHOR> https://arxiv.org/abs/2005.14242 <comment><USER2> I'd be more interested in a comparison in the strategies used to harden the codebase in the forks like BoringSSL and LibreSSL, and how well those strategies have panned out.

There has historically been some crowing from the LibreSSL crowd about how their work avoided CVE's later discovered in OpenSSL: [https://undeadly.org/cgi?action=article&sid=20150319145126](https://undeadly.org/cgi?action=article&sid=20150319145126)

<comment><USER3> I've been doing differential fuzzing of many major cryptographic libraries. It currently tests symmetric crypto, some elliptic curve crypto, bignum arithmetic, message digests and MACs, KDFs, but not TLS, X509, ASN1 etc (yet). The list of bugs it has found so far can be viewed here [1].

The bug count per library can not be used as an absolute metric and not all bugs are security vulnerabilities (though many can be under specific circumstances).

BoringSSL has fewer bugs than LibreSSL, which has fewer bugs than OpenSSL. One of the reasons for this could be that the bug count is proportional to the complexity/SLOC: BoringSSL is smaller in terms of functionality (# of message digests, ciphers, ...) than LibreSSL, which is smaller than OpenSSL. OpenSSL sometimes commits new buggy code whereas BoringSSL does not, but OpenSSL has a higher commit frequency than BoringSSL, and BoringSSL might be aiming for a production-safe master branch where OpenSSL might not.

So it's not easy to derive a reliable metric from this, but with that said, you can't really go wrong with BoringSSL if it offers what you need.

[1] [https://github.com/guidovranken/cryptofuzz#bugs-found-by- cry...](https://github.com/guidovranken/cryptofuzz#bugs-found-by-cryptofuzz)

<comment><USER4> > but not TLS, X509, ASN1 etc (yet)

then this may interest you:

[https://blog.doyensec.com/2020/05/14/asn1fuzz.html](https://blog.doyensec.com/2020/05/14/asn1fuzz.html)

^^ ASN1 is really the bees-knees for fuzzing telecoms protocols in UMTS/LTE/5G etc and doesn't get enough love in other domains. It's a high learning curve but once you get beyond the _" standardese"_ language in the docs it's opening doors to opportunities in so many industries.

> BoringSSL has fewer bugs than LibreSSL, which has fewer bugs than OpenSSL. > One of the reasons for this could be that the bug count is proportional to > the complexity/SLOC

the openSSL codebase is notorious but I think it's also because it has been in existing for so long. if I look around today I see 2 camps: cryptographers and software engineers. letting sw-engineers do crypto is usually a bad idea but it's often worse when cryptographers start coding. it's almost like a variation of the old joke of _" the 2 most dangerous things in Tech are a sw- engineer with a soldering iron and a hw-engineer with a sw-patch"_ ... apart from complexity leading to bugs I'd also say there is another downside which is stronger in openssl: people end up using it wrongly which makes it a proverbial foot-gun for implenters.

> [1] > [https://github.com/guidovranken/cryptofuzz](https://github.com/guidovranken/cryptofuzz)

very cool thanks!!

</comment></comment></comment><comment><USER5> Code quality and hygiene mean absolutely nothing if you have a large number of academic types who use OpenSSL as the dumping ground for their pet research projects, that are enabled by default, of course.

Also, OpenSSL supports all kinds of ancient esoteric platforms that are essentially unused, yet were kept in the code base for sentimental reasons.

The real metric they should be looking at is the number of features/platforms/LOC removed from the project. Less code = less surface areas for exploits.

<comment><USER6> I think the multiplatform support is an interesting criticism but misunderstood.

I happened to be reading some OpenSSL code around the time of heartbleed and statically linking some of it in a project. I found a lot of the portability ifdefs were poorly done even for the standards of the 90s. It wasn't portability itself that was the issue, it was actual quality and in many cases the wrong abstractions in place.

One example that sticks out in my memory... There was a logger that had a Win32 ifdef. If you ran on Win32 it fed log messages directly to MessageBox(). Unless it detected the current process was an NT service, in that case it used another logging mechanism without asking. It wasn't actually "windows portability" or "windows support". _The whole thing wasn 't appropriate for a library._ It could have had a mechanism to give the log lines to the application as a C string and be done with it. Instead, it was mixing of library layer stuff and application layer stuff, or just ordinary library bloat.

The other huge example I recall was compliance with older configurations that were pre-C99. C99 is much more universal now vs 20 years ago, although there are a few things Microsoft still doesn't support. But again, a bunch of these things seemed to be handled with ifdefs at the call site, rather than put in a proper compatibility layer that only an older configuration gets.

It does seem that in the years since then, cruft has been removed not only in forks but also in the upstream project.

<comment><USER7> An aside my feeling about Microsoft and their lack of C99 support is the community was inexplicably too nice to them. As well as compilers defaulting to C89 instead of the latest.

Also as someone that has a code base that targets a dozen different pieces of hardware ifdef madness is a strong indication that your program architexture is broken. Sometimes it's unavoidable but you should think of ifdef's as another name for FIXME.

<comment><USER6> Microsoft has gotten a bit better at it after many years of zero progress. Vs2010 introduced stdint and stdbool. Vs2015 finally allowed mixed declarations and code. I think the most lacking piece lately is the named struct member initializers.

<comment><USER8> Almost all the progress made was necessary to support modern C++ standards, although it is nice they enabled it in the C compiler. They haven't added any C only features in a very long time.

</comment></comment></comment></comment></comment><comment><USER9> I'm glad there have been changes to the project. Heartbleed was certainly bad, but I personally never understood getting behind LibreSSL. Seeing one bad vulnerability from an established project and immediately jumping ship to a brand new one with less eyes and reputation seemed hasty to me.

<comment><USER10> As the LibreSSL devs have said, heartbleed was not the cause of the fork. They forked the project because they believed the OpenSSL project repeatedly made bad decisions.

From [https://www.openbsd.org/papers/eurobsdcon2014-libressl.html](https://www.openbsd.org/papers/eurobsdcon2014-libressl.html)

> Heartbleed can't even be considered the worst OpenSSL vuln. Previous bugs > have resulted in remote code execution. Anybody remember the Slapper worm? > That worm exploited an OpenSSL bug (which was apparently titled the SSLv2 > client master key buffer overflow) which revealed not only encrypted data or > your private key, but also gave up a remote shell on the server, and then it > propogated itself. Yeah, I'd say that's worse. But no headlines.

> I mention this just to reinforce that LibreSSL is not the result of "the > worst bug ever". I may call you dirty names, but I'm not going to fork your > project on the basis of a missing bounds check.

> why fork

> Instead, libressl is here because of a tragic comedy of other errors. Let's > start with the obvious. Why were heartbeats, a feature only useful for the > DTLS protocol over UDP, built into the TLS protocol that runs over TCP? And > why was this entirely useless feature enabled by default? Then there's some > nonsense with the buffer allocator and freelists and exploit mitigation > countermeasures, and we keep on digging and we keep on not liking what we're > seeing. Bob's talk has all the gory details.

You can see "Bob's talk" here: [https://www.openbsd.org/papers/bsdcan14-libressl/](https://www.openbsd.org/papers/bsdcan14-libressl/) though I think there is a YouTube video somewhere.

Also I would like to point out that Google also forked OpenSSL. So it seems that the LibreSSL folks are not the only ones who thought a fork was necessary.

<comment><USER11> Damn OpenSSL sounds a lot worse than I thought after reading those slides. The custom malloc, the function that allow you to jump anywhere in OpenSSL, the 17 layer deep IFDef, the dubious entropy that openSSL try to generate if the OS doesn't provide it, the bugs that sit in the issue tracker for years.

A lot of that uglyness seems to come from the fact that OpenSSL wants to support all environments (even DOS). I wonder why distributions haven't switched since LibreSSL was made to be API/ABI compatible with openSSL and target a POSIX OS. This would be much more justified than the ffmepg / libav thing imo.

<comment><USER12> >LibreSSL was made to be API/ABI compatible with openSSL and target a POSIX OS

LibreSSL is neither API compatible with newer OpenSSL versions, nor is it ABI compatible. In fact, they break ABI every six months. Furthermore LibreSSL upstream only targets OpenBSD, with the portable version existing as an afterthought.

The only linux distribution using LibreSSL is Void Linux (Alpine switched to OpenSSL some time ago). Even Void is considering switching to OpenSSL: [https://github.com/void-linux/void- packages/issues/20935](https://github.com/void-linux/void- packages/issues/20935) .

<comment><USER11> Thank you ! That was interesting read. The main problems with LibreSSL are software compatibility since most software only build against OpenSSL and performance because the portable version doesn't include optimisations for other platforms than x86_64

The slides came out in 2014 so the API / ABI thing was probably true then but not anymore.

Maybe things would have been different if LibreSSL was backed by a major Linux distribution and OpenBSD. Even then Unix/Linux is not the only target of a lot of software and I doubt a lot of developer would have put the time to support both.

[Edit] I just saw in an other comment that LibreSSL is used in MacOSX and windows for openSSH. Maybe developers will consider it if it becomes available on major platforms

<comment><USER13> Apple uses LibreSSL as I understand.

<comment><USER14> Yes, but it's only for use by system libraries. The header files aren't shipped, and applications should use their own copy rather than trying to use the system's.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> This made me think of BoringSSL and LibreSSL again.

Looking up on Wikipedia it seems that LibreSSL is focused on OpenBSD and removed lots of legacy code. BoringSSL (Google) got renamed to Tink but I couldn't not find much more.

It's sad to see that duplication of effort but it's also the force of open source

<comment><USER15> The paper points to data showing that OpenSSL is still the dominant SSL implementation on the net, so it's the one that matters.

<comment><USER2> If Windows is the dominant desktop computing platform, is it the only one the matters?

</comment></comment></comment><comment><USER16> For random reasons I can't read the full article but I wonder if they discuss the impact of LibreSSL on OpenSSL itself. Would anyone who moved to LibreSSL actually look back to OpenSSL today in 2020? Honest question as I'm not a crypto professional myself.

<comment><USER15> It's just a PDF link. The paper mentions the existence of LibreSSL but that is pretty much it; the focus of the paper is on the extensive efforts to improve OpenSSL.

</comment></comment><comment><USER17> OpenSSL recently passed a change in their vuln announcement policy to give a major firm, which everyone here knows I think, 7 days advance notice of any zero-day that they were made aware of.

This was the engineer who helped set up the new policy: [https://awe.com](https://awe.com)

To be honest, maybe it's a good idea. It depends on how much support Huawei is willing to give OpenSSL.

<comment><USER18> So, being realistic here, that means the Chinese government is given 7 days advance notice?

<comment><USER19> [https://xenproject.org/developers/security- policy/#organizat...](https://xenproject.org/developers/security- policy/#organizations-on-the-pre-disclosure-list)

</comment></comment></comment><comment><USER20> What's the current market share of OpenSSL vs LibreSSL vs alternatives?</comment>


Independent moviehouses often struggle to keep the lights on - <AUTHOR> https://www.seattletimes.com/entertainment/movies/seattles-ark-lodge-cinemas-difficulties-illustrate-the-challenges-facing-independent-moviehouses/ <comment><USER2> Lived just a few blocks from the Ark Lodge and loved going to see films here. Unfortunately I just don't see it surviving for much longer without some form of additional help as mentioned in the article.

</comment><comment><USER3> He needs a bar which he admits he doesn't have..

</comment><comment><USER4> What is the difference between a movie house and a movie theater?</comment>


Getting started with Salt: a Puppet/Chef alternative built in Python on ZeroMQ - <AUTHOR> http://www.linuxjournal.com/content/getting-started-salt-stack-other-configuration-management-system-built-python <comment><USER2> There is also Ansible [1] which is written in Python and connects to servers using SSH (combined with sudo if needed). This means you don't need to install anything on the servers you're managing, since most distributions have Python >= 2.4 included. For more details see the requirements page [2].

[1] <http://ansible.cc/>

[2] <http://ansible.cc/docs/gettingstarted.html#requirements>

<comment><USER3> Can someone who has used both chime in? I've used ansible a bit and like it, but I've never heard of Salt before.

<comment><USER4> I'm hoping for this too. Especially somebody who has used both exhaustively. At first glance the architecture of both seems to be pretty sensible, clean, minimal and good in all the ways that puppet isn't. I half heartedly picked salt based upon the following:

* More commits in github. * More pull requests in github. * Main website is ranked higher by alexa.

However, after using salt for a short while, I ran into a couple of problems (no mercurial state, no ability to specify versions when using a pip state), which ansible seemed to be able to handle.

So, I don't know... salt seems to be more popular. A bit. That's all I can tell.

<comment><USER5> Ansible is moving at a pretty good clip too.

We do strongly encourage squash commits so I wouldn't go by counts alone, but pick what tool you like to use most and that best fits your needs, and your style, and what you want to do with it.

<comment><USER4> Well, that's the problem...both look good to me. Similar style, technologies and philosophy behind both.

I'd really appreciate a deeper comparison, though - especially if you feel that there are certain areas/circumstances where ansible may shine over salt.

<comment><USER5> Sure, you can see some of my comments here.

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

Main thing on Ansible is the focus on multi-tier and process orchestration, without having to rely on coding up event paths between nodes -- admittedly it's a niche problem, but to me, deployment is as important as config management, and often harder. That being said you can write deployment in anything if you try hard enough, but I built what fit my brain and the particular needs of a few past companies deploying multi-tier web apps. While it is easy to have ad-hoc in the product (Puppet also does this with mCollective), it's a bit harder to be able to both model deployment and declarative state, and then make that into content you can hand over to a security auditor who doesn't know the language and he can say, yep, that's exactly what we want.

</comment></comment></comment></comment></comment></comment><comment><USER6> Salt starts off with negative marks because they decided to type the letters A-E-S in their codebase: [https://github.com/saltstack/salt/blob/develop/salt/crypt.py...](https://github.com/saltstack/salt/blob/develop/salt/crypt.py#L281)

Specifically, they appear to be doing AES-CBC with HMAC-SHA256. There's nothing obviously wrong with it (randomized IVs from os.urandom, both authentication and encryption and with distinct keys...) but I would hope the standard for cryptography is higher than "nothing obviously wrong with it". Specifically, I would hope that the standard for cryptography is somewhere along the lines of using a peer-reviewed cryptosystem that has stood the test of time such as TLS, OpenPGP or even NaCl (given the name, particularly the latter would be pretty good). I'm not saying TLS doesn't have flaws; I'm saying appropriately configured TLS is better than rolling your own crypto.

I'm not entirely sure why they did that, but my best guess is that ZeroMQ pretty much doesn't support TLS.

<comment><USER7> <http://docs.saltstack.org/en/latest/topics/index.html>

""" Salt takes advantage of a number of technologies and techniques. The networking layer is built with the excellent ZeroMQ networking library, so the Salt daemon includes a viable and transparent AMQ broker. Salt uses public keys for authentication with the master daemon, then uses faster AES encryption for payload communication; authentication and encryption are integral to Salt. Salt takes advantage of communication via msgpack, enabling fast and light network traffic. """

<comment><USER6> That explains the feature set, but it doesn't quite explain why it doesn't use TLS; TLS _also_ starts with public key cryptosystems and then generates signing and symmetric encryption keys, oftentimes using precisely the same base algorithms (AES-256 and HMAC-SHA256).

(Also, msgpack seems completely orthogonal to this issue.)

<comment><USER8> It's not really as easy as "use X library". As another commenter mentioned - using stunnel _might_ be better than "rolling your own" based on well tested primitives, but "just using openssl" isn't necessarily a good solution, see eg this recent discussion:

[http://lists.randombit.net/pipermail/cryptography/2012-Octob...](http://lists.randombit.net/pipermail/cryptography/2012-October/003376.html)

</comment></comment></comment></comment><comment><USER9> I don't really consider salt as an alternative to puppet/chef.

Although it can do many of the same things as both of them, there are a few important differences. 1) By default, it encourages the use of YAML definitions which makes the codebase more readable/manageable over time. 2) It incorporates a first-class remote execution environment that replaces the need for parallel ssh or ssh almost entirely. 3) It leverages zmq as a data bus, and can easily transfer files or live data over the bus in multiple different topologies. 4) It uses python instead of ruby, which to many sysadmins & devops engineers used to bash scripting is generally more readable than ruby code.

Ansible shares a lot of similar characteristics, and it's great seeing both projects taking off. Definitely room for more than one system in this area, and everyone benefits from the healthy competition. It's not terribly complicated to have different systems manage different parts of your stack anyhow. You can easily use chef/salt/ansible all at once and use each project to manage different layers of your stack.

Just don't use capistrano... :-)

<comment><USER10> > It uses python instead of ruby, which to many sysadmins & devops engineers > used to bash scripting is generally more readable than ruby code.

I disagree. If anything, Ruby is closer to Bash (in a good way, mind you) whereas Python's various syntax choices (white-space sensitivity, parens for function calls, some things only available as imported modules, etc.) makes it more _different_.

Consider bash:

        if [ `which foo` == "/usr/bin/foo" ]; then
          do_stuff
        fi

compared to Ruby:

        if `which foo`.strip == "/usr/bin/foo"
          do_stuff
        end

compared to Python:

        import os
        if os.popen("which foo").read().strip() == "/usr/bin/foo":
          do_stuff()

Also, I would be careful about making generalizations without the data to back it up. "Many sysadmins & devops prefer..." is what Wikipedia editors would call weasel words.

I have only anecdotal evidence myself; I personally used to be a Python guy but now prefer Ruby; and some time ago my company hired a sysadmin/devops guy who came from Python, but grew to prefer Ruby once he started to learn it while working for us.

Considering that both Puppet and Chef are written in (almost entirely) Ruby, I would say that the sysadmin/devops field is currently leaning more strongly toward Ruby than Python. Although I'm sure bash dominates both.

Don't get me wrong, in terms of productivity and so forth, Python and Ruby are entirely on an equal footing.

<comment><USER11> I generally agree with your response. My only slight irritation is with how you wrote out the Python code. It looks a bit...uglier? and more verbose than it needs to be, especially compared to the others. This looks better to me:

      from commands import getoutput
      if getoutput('which bash') == '/bin/bash':
          do_stuff()

Although if your goal is to determine if e.g. bash is located in /bin, then I would do:

bash:

      if [ -e '/bin/bash' ];
      then
          do_stuff
      fi

(I don't know Ruby.)

Python:

      import os.path
      if os.path.exists('/bin/bash'):
          do_stuff()

I know I'm just splitting hairs. :)

<comment><USER10> The point was definitely not the logic of the examples! Rather to show three core similarities/differences:

* Ruby has bashisms like `foo`; Python requires a function call.

* Ruby has a nesting syntax similar to bash with if/end; Python is whitespace-sensitive.

* Ruby has method calls without parentheses, similar to bash commands, whereas Python requires them.

> Although if your goal is to determine if e.g. bash is located in /bin,

Actually, that was not the goal at all. The goal (which, again, is irrelevant to my point) was to determine if the PATH-resolved executable binary "foo" was in a specific location. Rest assured that I would not use "which" in a real- life app. :-)

(Thanks for commands.getoutput(), my Python is rusty.)

</comment></comment></comment></comment><comment><USER12> I've been using Salt for about 10 months. It's pretty simple and is exceptionally fast when compared to many alternatives. Also, the code is absolutely clean, easy to read and well commented. We actually use Salt's code when we need an example of how to do python right... especially when you want to make diffs easy.

</comment><comment><AUTHOR> We've started using Salt for configuration management and it's everything we'd hoped for. It took some time to get our state tree figured out but now it works like a charm.

</comment><comment><USER13> I've kicked salt's tyres recently and really like it. I think me favourite aspects are being able to use jinja and the fact that everything is all in the same place for the definitions. (As opposed to spread around various json/ruby files in chef for example.)

</comment><comment><USER14> Salt is using its own homebrew transport encryption protocol instead of TLS (which, among other things, serializes everything as JSON o_O): [https://salt.readthedocs.org/en/latest/topics/specs/salt_aut...](https://salt.readthedocs.org/en/latest/topics/specs/salt_auth_proto_abs.html)

Why are they doing this? Good question!

<comment><USER15> ZeroMQ does not provide transport level encryption. By performing the encryption at the message level, it lets Salt publish the messages to everyone that is subscribed, but then only the minions that can decrypt the data actually run the code.

<comment><USER14> And what's the threat model for this protocol, exactly? How many cryptographers have actually studied it? Encrypted transport protocols are notoriously hard to get correct... just look at how many times TLS, SSH, and IPsec have been compromised.

Their abstract mentions little about the algorithms they're actually using. For example, they mention "RSA authentication" but not what authenticated encryption mode they're using (looking at the code, it's encrypt-then-HMAC. At least their MAC comparison function looks constant time-ish)

I don't think the people who created this have any business designing an encrypted transport protocol.

</comment></comment></comment><comment><USER16> I highly recommend Salt stack. It's a great piece of software: straightforward and gets the job done. After using Puppet, Chef and cfengine, I'm glad there's salt :)

</comment><comment><USER17> Didn't Salt build upon Func? And didn't the author of Func go on to write Ansible? My experience between Salt, Rundeck, Ansible, and Fabric was that Salt/Rundeck were too heavyweight and that between Ansible and Fabric, Ansible mopped the floor with Fabric. Just my $.02.

<comment><USER5> Yeah, I was one of the Func authors. That minion/overlord terminology, globbing, delegation, minion-to-minion, etc, are ideas clearly from there. I think mCollective was the first to take our Func-on-AMQP ideas and implement them, actually, though Salt was probably the first to try to stick a CM layer on the top of a Func-based-system, like I was planning but hadn't got around to ("Remote Rocket Surgery" was the placeholder codename for that on top of Func).

As far as Func->Ansible goes, Seth Vidal (another one of the original authors) also does a lot of commits and wrote our yum module -- and is now using it for Fedora Infrastructure.

I wouldn't really recommend anyone look at Func anymore -- it's fading just a little bit (taken over by Steve Salesvan, also ex Red Hat), but it's still in use at places like Tumblr, which is a pretty large setup. Still, it was fun to do. We sort of did multiprocessing before multiprocessing.py :)

Adoption is going pretty well at the moment and it has been fun to watch. Several setups in the couple thousand of node ranges, lots around Big Data applications.

</comment></comment><comment><USER18> So far I have only used salt at home in a lab environment, however it is promising. I especially love that I can dictate my directory structure for configuration by my own standards.

</comment><comment><USER19> Salt is a promising tool for configuration management and remote execution.

But I believe it's still in it's early stages and need to go way much much more. My colleague decided upon using salt instead of chef or puppet. I'm ok with this decision but had too made some tweaks and send bug fixes or features upstream while testing environment.

I believe there may be many more to come.

Still, it's easy to use, configure and also it's still really nice on the eyes with being python. It's trivial to make fixes to the code base.

</comment><comment><USER20> I'm currently a reasonably happy puppet user, but I do like the look of Salt. Puppet's configuration DSL always struck me as a little over-wrought (and slightly too inconsistent to remember easily). I would have preferred YAML/XML/ini files.

<comment><USER21> I complained about cfengine's syntax in a blog post a while ago[1]; someone mentioned that a patch for YAML-based cfengine manifests had been proposed. I haven't seen anything since, but then ... well I don't follow the cfengine news too closely.

It largely seems to be that a lot of these systems take their directives as nestable key-value pairs, so I think YAML is a good fit.

Amusingly, the first link someone posted on my blog post was to Salt. I didn't dig too deep at the time as it appeared to be more at the REF end of the spectrum to me.

[1] [http://chester.id.au/2012/06/27/a-not-sobrief-aside-on- reign...](http://chester.id.au/2012/06/27/a-not-sobrief-aside-on-reigning-in- chaos/)

</comment></comment><comment><USER22> Met the guys behind Salt recently, and they seem pretty nice and host the local Python meetup. I'd like to try to use it some time, but the docs seem a bit on the impregnable side; while it seems they have decent coverage, there isn't a lot to really glue it all together and from just a quick skim, it seems like it'd be a pain to start from those. They should really invest in some decent "Getting Started"/tutorial blocks and attempt to explain the concepts narratively. I noticed perhaps a bit of this, but as I said, on a quick skim, it seemed quite insufficient.

</comment><comment><USER23> Also there is cdist (<http://www.nico.schottelius.org/software/cdist/>) not so popular but interesting.

<comment><USER24> It seems that cdist recipes must be written as shell scripts.

<comment><USER25> That is absolutely right - and thus your sysadmins do not need to learn a new language / DSL. cdist is mostly about being simple

</comment></comment></comment><comment><USER26> Just when I narrowed my options down to ansible and chef…

This seems to be more in line with chef/puppet, with a dedicated daemon on the client.

<comment><USER4> It's more similar to ansible than puppet. Both are python based and use zeromq. All four are declarative and AFAIK, all four have a dedicated daemon on the client.

<comment><USER5> I would rather not get into "X is better than Y", but this is not quite accurate.

I'm not saying that's a bad thing, but I see a distilled Puppet syntax there, where Ansible (<http://ansible.cc>) is more about modeling both resource states and ordered processes across machines.

Ansible actually uses SSH by default but there's a 0mq accelerator if you want to use it. We don't just execute individual SSH commands, modules are remote resources that model idempotent state -- but don't stay resident. The 0mq accelerator came later. There's also a pull mode, and a local mode in Ansible. Using SSH is nice because you don't have the additional PKI, and all that comes with having to maintain that. (No needs of accurate NTP and DNS either, and working with Kerberized SSH and using your OS credentials is possible). Need to do non-root things? You can do things (if you have permissions) entirely as non-root.

Furthermore, Ansible does not have a dedicated daemon on the client. It's daemonless, and consumes no resources when not running. When running with 0mq, the daemon is ephemeral, stopping after a set period of time, to not consume resources.

It also requires no bootstrapping, so if you have blank cloud images with nothing on them, or brownfield systems in the field, you can just start managing them immediately. cloud-init and so on are great for this, all cloud tools can inject keys. For this reason (no agents), it's starting to look very appealing on embedded devices and network hardware as well.

While implemented in Python you can write modules in any language. Finally, Ansible's core focus is around making multi-tier orchestration easy (somewhat of a niche case), so that leads it to look a lot different at the language/resource level. But if you have just one tier, you can use it too.

It's frequently used to deal with rolling updates involving N-tier applications with monitoring servers and load balancers all in play, though you can definitely use Ansible just for classical config management.

I think part of the reason Salt may look similar to Ansible is Salt is clearly inspired by Func, especially the minion/overlord terminology, globbing, minion-to-minion, etc, and I was one of the original authors of Func at Red Hat. We were toying around with a message bus Func at the time and decided not to do it.

So, yeah, lots of tools in this space.

In Ruby config land, there's also Sprinkle, Rexify, etc! So many options!

<comment><USER27> _> In Ruby config land, there's also Sprinkle, Rexify, etc! So many options!_

The Rexify (or more precisely Rex) that I'm aware of is written in Perl - <http://rexify.org/> | <https://github.com/krimdomu/Rex>

</comment></comment></comment></comment><comment><USER28> Is there a search functionality, similar to what Chef::Search provides ?

</comment><comment><USER29> Why?</comment>


Do Women Handle Start-Ups Better Than Men? - <AUTHOR> http://blogs.wsj.com/independentstreet/2009/01/15/do-women-handle-start-ups-better-than-men/ <comment><USER2> During my unemployment phase I would hide in between the aisles in between business books and technical books of Borders from opening till closing. One thing I've mastered was the art of reading business books. It's really simple: open up a business book with catchy hook, flip through the table of content, note the chapter titles, close book. There. That's all you need.

<comment><USER3> I like to make the distinction between "airport" business books and "business school" business books. It's a useful distinction, simply because compared to engineering, business is hard (Anyone can build a product, selling it and making it succeed is hard). The problem is that the vast majority of successful people will talk about the "airport" business book that was the key to their success because their experience was primary based on luck, with some crappy motivational type writing along the way (Hey, Tim Ferris, I'm talking about you).

Michael Porter is an excellent place to start if you want to read thoughtful writing on how to actually create successful businesses. Just expect it to be as challenging as a good technical book.</comment></comment>


Ask HN: Where Django folks hang out online? - <AUTHOR>

Where can I find the community? <comment><USER2> #django maybe?</comment>


New Query Language for Graph Databases to Become International Standard - <AUTHOR> https://neo4j.com/press-releases/query-language-graph-databases-international-standard/? <comment><USER3> There is an ISO-standardized graph query language: Prolog and its decidable fragment Datalog, both widely used (relatively) for decades. Will the new language be based on it?

Another question is whether the model having driven ISO standardization in the past (software vendors working together to create a large, visible, and diverse market) is still relevant in post-standard cloud times. I sure hope it is, but we haven't seen public demand for standards (with the exception of web standards) for well over a decade now.

<comment><USER4> I think the cloud times renews the need for standards. Ten years ago devs in the linux/BSD world had the vast majority of the code that would make up our stack, from OS kernel to the front end (with perhaps some proprietary driver or external API call here or there).

The code was the standard, which traded easy readability for complete accuracy and transparency.

<comment><USER3> > _The code was the standard_

That's emphatically _not_ what a standard is about. Standards in the field you described were developed over many years by proprietary Unix vendors (including BSD as descendents of the original TCP/IP stack), enshrined in POSIX/SUS (also published as Open Group and ISO standards), and then implemented on Linux. Apart from early RedHat stuff such as PAM and things like LSB, it is only since about 2005 or so that Linux dominates the market by de-facto implementations rather than standards (such as bash, Docker-style containers based on Linux namespaces, etc.)

<comment><USER4> Of course that's not what a standard is about, but I believe it's what happened for technologies during the time that standards fell off.

I identified 2009 as about when you expected de facto open source implementations instead of any talk of standards but I would buy 2005 as well. Obviously it's a fuzzy boundary.

</comment></comment></comment></comment><comment><USER5> I spent many years working on a Neo4j Ruby gem and really grew to love Cypher, their query language. I always found it phenomenally expressive, one of those things that seems simple (almost trivial) at first but was extremely flexible and powerful when you needed more from it. It's highly readable, easy to teach, and intuitive in a way that I never found SQL to be.

It's been years since I've worked with the product and while I don't miss Neo4j, I do miss the query language. It's a little unclear to me how GQL will incorporate Cypher but I hope the initiative is successful if for no other reason than a selfish one: I'd love Cypher to be around if I ever wind up using a GraphDB again.

<comment><USER6> > It's been years since I've worked with the product and while I don't miss > Neo4j, I do miss the query language

Would you mind expanding on what you don't miss about Neo4j?

<comment><USER5> I was trying to use it instead of Postgres as a general database and it just didn't shine in that role. The value proposition made sense on paper: it's a more natural way to reason about data than RDBMS, relationships as first-class citizens offer some really great benefits, avoiding the schema seems reasonable when the rest of your stack is dynamic, Cypher is more pleasant than SQL. While some of that might be true, I encountered the following:

\- Using a somewhat esoteric database increased my devops responsibilities.

\- Open source license didn't allow hot backups.

\- Ruby is just slow. I was using it before the binary protocol was implemented so performance was often lousy compared to Postgres.

\- Writes were slow. Neo4j seemed to excel at reads and, in particular, the kinds of reads that are best handled by a graph. Shocking, I know.

\- I really didn't have enough data or the need for the kinds of queries that would really let it shine.

\- A big part of the culture at meetups and tutorials was based on "DON'T YOU JUST HATE JOINS!?" It felt culty. I was a big part of that problem for a long time. The last meetup I went to just felt like people bashing Postgres.

So I think that a lot of the things that I don't miss are because I wasn't right for it, I should have just been using Postgres.

All that said, there was so much about it to love. Cypher, as already mentioned. While the culture at meetups might have kind of relied on bashing SQL and RDBMS, the company itself was full of brilliant, generous, creative, wonderful people. Their CEO (Emil) in particular is a total sweetheart. The organization was extremely supportive of open source projects, very inclusive, very eager to get people involved, and it made a big impact on me.

So, again, while Postgres is the tool I always reach for first, I think that Neo4j as an organization does great work and as a product has a lot to offer if you're the right fit for it. I'm glad to see they're doing well.

</comment></comment></comment><comment><USER7> So, is there a draft spec yet? I can't find anything.

Also, the name is of course justified, but it will be a mess to search for due to (Facebook) GraphQL.

<comment><USER8> Is GQL already used elsewhere? As long as nobody calls it graphql we should be fine, right? Nobody says structured ql or even structured query language, its just sql.

<comment><USER9> Yes, it's used by a lot of GraphQl libraries:

        graphql-python/gql: A GraphQL client in Python

        graphql-python/gql-next: A Python GraphQL Client

        grooviter/gql: Groovy GraphQL library

        99designs/gqlgen: go generate based graphql server

</comment></comment></comment><comment><USER10> That's quiet an unfortunate name clash with the existing GraphQL language in a similar domain.

<comment><USER11> I think GQL from Neo4J has been around for quite a while before GraphQL.

<comment><USER12> > I think GQL from Neo4J has been around for quite a while before GraphQL.

Cypher has been, GQL has not.

GQL from _Google_ has, but that's another problem with the (EDIT: naming of the) new GQL.

<comment><USER13> How would you think anyone should call a graph query language done by the SQL committee?

<comment><USER12> SGQL? SQL-GRAPH? G?

Or, heck, Cypher (with SQL itself, and most other languages, ISO didn't change the name even though the spec they adopted didn't necessarily exactly match what existed previously, they kept the name of the existing language they were standardizing.)

</comment></comment></comment></comment></comment><comment><USER14> What's wrong with SPARQL? What advantages has this over SPARQL?

<comment><USER15> Very few real advantages on a technical level.

Practically, the PG model has many syntactic advantages over the equivalence in expression power RDF+reification. (See excitement over RDF*, which is can be pure syntactic sugar) Syntax is important for usability.

I don't believe that PG in Cypher or GQL will be significantly more expressive than SPARQL 1.1. And in any case are quite different from the tinkerpop model.

I believe it is essential for Neo4J as a growing company that they move beyond their own Cypher to something that is more defined and critically allows them to check a "we are a standard" box on big deals. OpenCypher has solid adoption but lacks coherence between implementations. i.e. same data same query, different result.

Still a more grounded GQL will allow Neo4j competitors to gain on them.

<comment><USER16> > Still a more grounded GQL will allow Neo4j competitors to gain on them.

Can you expand on this? What do you mean?

<comment><USER15> Currently it is relatively difficult to move data from one (open)cypher implementation to an other. Also as support is uneven for all features it is not so simple to get started on Neo4J and then evaluate e.g. TigerGraph if you find that Neo4J is not ideal for your usecase.

If your application only uses GQL then you could start on Neo4J but after two years in production cheaply move to a competitor. By just switching your backend and run your test cases etc. your data did not change, your queries remain the same, so evaluation is relatively straightforward.

I see this quite often in the SPARQL world. First few years of a product is with engine A, then some annoyance in production show up. Engines B-D are evaluated and a different one is chosen. Or sometimes both are run at once for different query workloads on the same data. Which is relatively cheap in the SPARQL environment. But because of custom engineering in the property graph world to move from engine 1 to engine 2 it is much more expensive in engineering hours.

<comment><USER17> Basically Neo4J thrives on vendor lock-in and standards lower the lock-in.

</comment></comment></comment></comment></comment><comment><USER18> There is something really special about the graph database space. For as long as the space has been around (15 or so years), every vendor and dedicated practitioner has taken solid jabs at trying to realize "the best way" to think about graph traversals.

This behavior seems particular to the graph space (vs. document, wide-column, relational, key/value, etc.). While this speaks to the complexity of the type of problems you can solve with graphs, thinking back, I believe this was a cultural anomaly. When it was Neo4j, OrientDB, TinkerPop: the language trifurcation occurred.

I'm excited that Neo4j is continuing to take the query language seriously. In an age when software development is about making it easy for the 90% of developers out there with REST APIs, GraphQL, and overly SQL'd embeddings, ... graph is still searching for "that best way."

I, personally, have moved on from language-level. However, our new work is going to help my fellow data system colleagues get there languages exposed to as many developers as possible regardless of data model. It is important to me that people can come to respect the numerous ways in which we think about data and has the language we use is so important. The difference between living in Plato's Cave or not.

In an effort to support query languages in general, I'll be working on mm-ADT designing a new cluster-oriented virtual machine architecture for storage, processing, and query language developers. I see a veritable Tower of Babel on the horizon!

Congrats Neo4j on reaping the benefits of your hard work. I hope our work will converge in for a positive collaboration in 2020.

<comment><USER17> For some reason you neglect to mention RDF graph data model and its SPARQL query language, which have been W3C standards since 1997 and 2008, respectively.

They have a healthy ecosystem of both open-source and commercial software, and unlike property graphs were designed with data interchange in mind from the outset.

SPARQL was the first and still is the only standard NoSQL query language.

<comment><USER19> > , which have been W3C standards since 1997 and 2008, respectively.

While RDF forms a graph, it is not a general graph model. In particular, two things that are enabled by graph databases (having data in the node itself, and associating data with edge) are not directly possible and need tricks such as relationship reification.

On the social side, the sectarism and bikeshedding tendencies of the community can be another turn off.

<comment><USER17> RDF is a directed graph model. Nowhere does it say properties have to have properties in a graph model. You can always model them as intermediary nodes.

<comment><USER19> Using intermediate node is changing the structure of the graph. RDF is not a general graph model. The fact that a node cannot hold data by itself (a link to literal is required) is risible.

Naming of nodes with IRI is also a ridiculous, especially in Linked Data where changing your hosting domain (and even the protocol to access data) requires changing the data itself.

<comment><USER17> Are you kidding? IRIs is what sets RDF above and beyond other data models. Global identifiers are crucial if you want to work with data interchange on a web scale.

Show me a definition of a "general graph model"? Nothing shows up on Wikipedia.

There is on the other hand a directed graph model: [https://en.wikipedia.org/wiki/Directed_graph](https://en.wikipedia.org/wiki/Directed_graph) This is exactly what RDF is, with labeled vertices and edges.

<comment><USER19> You can have global identifier without IRIs, for example using GUID (that's the solution used for COM components for instance).

The thing is you can't represent "A"->"B" directly in RDF. You need to stretch the representation to at least use a resource node as subject, but also for the object too if this node could be used as subject in another predicate. And of course both these resources must be encoded as IRI and then linked to the literals that contains the data. That's four nodes and three links instead of two and one. It's a lot of boilerplate code for a simple problem. And as said before, putting key:value on an edge require reification of the edge... which undermine the simple SPO model because it's now SP(O as P)PO.

You may think it the same but it's not. Usability matters and that's why the SemWeb stack has almost zero adoption since its inception while graph databases are trendy.

<comment><USER17> > SemWeb stack has almost zero adoption since its inception while graph > databases are trendy

Where is my LOL GIF :D

RDF Knowledge Graphs used by: Elsevier, Bloomberg, Thomson Reuters/Refinitiv, Uber, Zalando, Microsoft, Apple, Amazon, HSBC... do I need to continue?

If you mean "mainstream developer" adoption, that is a poor and irrelevant indicator, because mainstream is not where the innovation happens.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> why did Tinkerpop's Gremlin not work out ? anyone has a summary of the discussion from a language design perspective ?

A lot of the Google-able references talk about how Gremlin is more optimizable than Cypher, etc.

<comment><USER21> Gremlin was written by a genius level developer to be used by other genius level developers. There are maybe a handful of Gremlin experts in the entire world and less than 100 that are any good at it.

It is extremely powerful, but after a few lines, the mental acrobatics needed to understand what the query does is beyond your average developer.

My first paid Neo4j gig 7 years ago was writing a rules engine in gremlin. It was about 25 lines of code. If you were to ask me today what each of those lines did, I would be at a loss. So would anyone who didn't live in those specific queries day in and day out.

Graph adoption was severely limited by its use. Cypher can be learned in a day, and "business people" can look at a cypher query and understand what is going on for the most part.

It takes about a week to "bolt on" Gremlin to any database. I've done it myself, that's why you see it so often. It takes months to be any good at it.

<comment><USER22> Far from a genius myself, I've quite enjoyed using Gremlin and the Apache Tinkerpop project. If you start thinking of it as a functional language, I believe that helps clarify quite a bit what is going on.

Unfortunately when using it with a distributed backend (Cassandra, for example), having to write query templates to take advantage of bit-wise comparisons for parameterizing, all in Groovy, was extremely painful mostly because I found Groovy to be very awkward.

But there are language-native protocol implementations of Gremlin now.

The little self-contained Apache Tinkerpop project was always fun to play with toy graphhs in.

And there was an ambitious project to implement the Tinkerpop engine on top of a Redis backend (akin to RedisGraph which is now an official module using Cypher) but it is far from a straightforward project. There is even a Tinkerpop implementation on top of PostgreSQL which looks interesting.

I'm not sure this is a death blow for Tinkerpop so much as a marketing coup the grace for Neo4J. They have a strong product (despite the index-free adjacency!) and an even strong branding behind it. Anything that brings graph DB/technologies into the mainstream is always nice, though. Not that everything in the world is a graph problem...but surely there are plenty that can be classified as such.

</comment></comment></comment><comment><USER23> I'm rather uninitiated on this... what's the difference between a graph database and a traditional relational database that makes them need different query languages?

<comment><USER24> SQL generally doesn't have primitives that let you traverse arbitrary relationships. You can join multiple tables together, but the nature of those relationships is expressed directly in the SQL statement you're writing.

Some RDBs provide extensions to the SQL standard to do some basic graph traversals (Oracle's CONNECT BY, for example), but these are just the most- basic sorts of graph traversals.

In a graph database, the primary notions are nodes and edges and properties associated with them, whereas in a relational database, the primary notions are tables (aka "relations"), foreign keys that allow you to connect together multiple tables, and rows in those tables. Those differences in primary notions surface in the query languages as well.

<comment><USER23> Thanks for the response. I'm having trouble seeing what kinds of queries come up of this nature that SQL wouldn't be fit for, though. What would be an example of a realistic graph query one would want to do that would be too difficult to do in SQL?

<comment><USER24> Let's assume we're playing the Kevin Bacon game. We've got actors, movies, and roles. Here's some sample data:

        INSERT INTO actors (id, name) VALUES (1, 'Kevin Bacon')
        INSERT INTO actors (id, name) VALUES (2, 'Frank Langella')
        INSERT INTO actors (id, name) VALUES (3, 'Cameron Diaz')

        INSERT INTO movies (id, name) VALUES (1, 'The Box')
        INSERT INTO movies (id, name) VALUES (2, 'Frost/Nixon')

        INSERT INTO roles (movie_id, actor_id) VALUES (1, 2)
        INSERT INTO roles (movie_id, actor_id) VALUES (1, 3)

        INSERT INTO roles (movie_id, actor_id) VALUES (2, 1)
        INSERT INTO roles (movie_id, actor_id) VALUES (2, 2)

Given the above data model, it's not possible to select all the actors that are within 6 degrees of Kevin Bacon with a SQL statement.

(Data from the incredible Oracle of Bacon, which uses custom graph traversal to serve up results: [https://oracleofbacon.org/how.php](https://oracleofbacon.org/how.php))

<comment><USER25> This is an elegant and simple formulation of the problem and shows how bad SQL is at this. However, you can do this in SQL.

        with recursive bacon_movies as (
            select
                a.id as actor_id
                , 0 as bacon_degree
            from
                actors a
            where
                a.name = 'Kevin Bacon'
            union
            select
                r1.actor_id
                , b.bacon_degree + 1 as bacon_degree
            from
                bacon_movies b
            join roles r on r.actor_id = b.actor_id
            join roles r1 on r.movie_id = r1.movie_id and r1.actor_id <> b.actor_id
            where b.bacon_degree < 6
        )
        select
            a.name
            , min(b1.bacon_degree) as bacon_degree
        from bacon_movies b1
        join actors a on a.id = b1.actor_id
        group by a.name
        order by bacon_degree asc;

...not saying it's a good way to do this

<comment><USER26> > ...not saying it's a good way to do this

It really depends. If you do these kinds of queries all the time, it's a good idea to use a graph DB, but if these queries are rare, it often doesn't make sense to add a new technology to your project.

</comment></comment></comment></comment></comment></comment><comment><USER27> Should GQL be pronounced with a hard or soft G?

Is "geequel" going to take off akin to "sequel" for SQL?

</comment><comment><USER28> oh good, I wonder if they realize developers frequently refer to GraphQL as gql.

</comment><comment><USER29> So will neo4j switch to gql? and will spark support switch to gql?

<comment><USER30> Yup, you can think of ISO GQL as the future of Cypher.

</comment></comment><comment><USER31> So if I want to learn this GQL, where do I even start? I'm also confused about the naming, is there more than one language that could be called GQL?

<comment><USER30> While the ISO GQL standards draft is being prepared, the best way for a developer to learn and prepare for ISO GQL is to learn the Cypher query language.[1] Many of the concepts from Cypher will be carried over into ISO GQL.

[1]: [https://neo4j.com/developer/cypher- basics-i/](https://neo4j.com/developer/cypher-basics-i/)

</comment></comment><comment><USER32> Isn't xquery basically a graph query language similar to GraphQL? If so, why are we not using xquery to query objects and sub-objects?

<comment><USER33> I'm not familiar with xquery, does it handle general graphs or only DAGs? Your mention of "objects and sub-objects" makes me think you're expecting a different use-case than actual graph databases, which deals more with peer-to- peer connections (like knowledge graphs) than hierarchical models.

</comment></comment><comment><USER34> Anyone know the difference with ArangoDB's AQL ? (I haven't use neo4j as I use ArangoDB)

<comment><USER13> AQL is a vendor-specific multi model language that lately has picked up some ideas from openCypher, like pattern matching.

GQL is a project for creating an International Standard language in the process of being created by experts from many countries that represent the interests of multiple vendors.

</comment></comment><comment><USER35> Huh.

Now if only we could do this for configuration management, service mapping/scheduling/coordination, resource allocation, monitoring, alerting, logging, access control, artifact packaging, and execution pipelines.

</comment><comment><USER36> What advantages/limitations does it have compared to SHACL? [https://en.m.wikipedia.org/wiki/SHACL](https://en.m.wikipedia.org/wiki/SHACL)

</comment><comment><USER37> Graph query languages are nice and all, but what about Linked Data here? Queries of schemaless graphs miss lots of data because without a schema this graph calls it "color" and that graph calls it "colour" and that graph calls it "色" or "カラー". (Of course this is also an issue even when there is a defined schema; but it's hardly possible to just happen to have comprehensible inter or even intra-organizational cohesion without e.g. RDFS and/or OWL and/or SHACL for describing (and changing) the shape of the data)

So, the task is then to compile schema-aware SPARQL to GQL or GraphQL or SQL or interminable recursive SQL queries or whatever it is.

For GraphQL, there's GraphQL-LD (which somewhat unfortunately contains a hashtag-indeterminate dash). I cite this in full here because it's very relevant to the GQL task at hand:

"GraphQL-LD: Linked Data Querying with GraphQL" (2018) [https://comunica.github.io/Article-ISWC2018-Demo- GraphQlLD/](https://comunica.github.io/Article-ISWC2018-Demo-GraphQlLD/)

> _GraphQL is a query language that has proven to be a popular among > developers. In 2015, the GraphQL framework [3] was introduced by Facebook as > an alternative way of querying data through interfaces. Since then, GraphQL > has been gaining increasing attention among developers, partly due to its > simplicity in usage, and its large collection of supporting tools. One major > disadvantage of GraphQL compared to SPARQL is the fact that it has no notion > of semantics, i.e., it requires an interface-specific schema. This therefore > makes it difficult to combine GraphQL data that originates from different > sources. This is then further complicated by the fact that GraphQL has no > notion of global identifiers, which is possible in RDF through the use of > URIs. Furthermore, GraphQL is however not as expressive as SPARQL, as > GraphQL queries represent trees [4], and not full graphs as in SPARQL._

> _In this work, we introduce GraphQL-LD, an approach for extending GraphQL > queries with a JSON-LD context [5], so that they can be used to evaluate > queries over RDF data. This results in a query language that is less > expressive than SPARQL, but can still achieve many of the typical data > retrieval tasks in applications. Our approach consists of an algorithm that > translates GraphQL-LD queries to SPARQL algebra [6]. This allows such > queries to be used as an alternative input to SPARQL engines, and thereby > opens up the world of RDF data to the large amount of people that already > know GraphQL. Furthermore, results can be translated into the GraphQL- > prescribed shapes. The only additional requirement is their queries would > now also need a JSON-LD context, which could be provided by external domain > experts._

> _In related work, HyperGraphQL [7] was introduced as a way to expose access > to RDF sources through GraphQL queries and emit results as JSON-LD. The > difference with our approach is that HyperGraphQL requires a service to be > set up that acts as a intermediary between the GraphQL client and the RDF > sources. Instead, our approach enables agents to directly query RDF sources > by translating GraphQL queries client-side._

All of these RDFS vocabularies and OWL ontologies provide structure that minimizes the costs of merging and/or querying multiple datasets: [https://lov.linkeddata.es/dataset/lov/](https://lov.linkeddata.es/dataset/lov/)

All of these schema.org/Dataset s in the "Linked Open Data Cloud" are easier to query than a schemaless graph: [https://lod-cloud.net/](https://lod- cloud.net/) . Though one can query schemaless graphs with SPARQL, as well.

For reference, RDFLib has a bunch of RDF graph implementations over various key/value and SQL store backends. RDFLib-sqlachemy does query parametrization correctly in order to minimize the risk of query injection. FOR THE RECORD, SQL Injection is the CWE Top 25 #1 most prevalent security weakness; which is something that any new spec and implementation should really consider before launching anything other than an e.g. overly-verbose JSON-based query language that people end up bolting a micro-DSL onto. [https://github.com/RDFLib/rdflib- sqlalchemy](https://github.com/RDFLib/rdflib-sqlalchemy)

Most practically, I frequently want to read a graph of objects into RAM; update, extend, and interlink; and then transactionally save the delta back to the store. This requires a few things: (1) an efficient binary serialization protocol like Apache Arrow (SIMD), Parquet, or any of the BSON binary JSONs; (2) a transactional local store that can be manually synchronized with the remote store until _it 's_ consistent.

SPARQL Update was somewhat of an out-of-scope afterthought. Here's SPARQL 1.1 Update: [https://www.w3.org/TR/sparql11-update/](https://www.w3.org/TR/sparql11-update/)

Here's SOLID, which could be implemented with SPARQL on GQL, too; though all the re-serialization really shouldn't be necessary for EAV triples with a named graph URI identifier: [https://solidproject.org/](https://solidproject.org/)

5 star data: PDF -> XLS -> CSV -> RDF (GQL, AFAIU (but with no URIs(!?))) -> LOD [https://5stardata.info/en/](https://5stardata.info/en/)

<comment><USER16> Linked Data tends to live in a semantic web world that has a lot of open world assumptions. While there are a few systems like this out there, there aren't many. More practically focused systems collapse this worldview down into a much simpler model, and property graphs suit just fine.

There's nothing wrong with enabling linked data use cases, but you don't need RDF+SPARQL+OWL and the like to do that.

The "semantic web stack" I think has been shown by time and implementation experience to be an elegant set of standards and solutions for problems that very few real world systems want to tackle. In the intervening 2 full generations of tech development that have happened since a lot of those standards were born, some of the underlying stuff too (most particularly XML and XML-NS) went from indispensable to just plain irritating.

<comment><USER37> > _Linked Data tends to live in a semantic web world that has a lot of open > world assumptions. While there are a few systems like this out there, there > aren 't many. More practically focused systems collapse this worldview down > into a much simpler model, and property graphs suit just fine._

Data integration is cost prohibitive. In n years time, the task is "Let's move all of these data silos into a data lake housed in our singular data warehouse; and then synchronize and also copy data around to efficiently query it in one form or another"

Linked data enables data integration from day one: enables the linking of tragically-silo'd records within disparate databases

There are very very many systems that share linked data. Some only label some of the properties with URIs in templates. Some enable federated online querying.

When you develop a schema for only one application implementation, you're tragically limiting the future value of the data.

> _There 's nothing wrong with enabling linked data use cases, but you don't > need RDF+SPARQL+OWL and the like to do that._

Can you name a property graph use case that cannot be solved with RDFS and SPARQL?

> _The "semantic web stack" I think has been shown by time and implementation > experience to be an elegant set of standards and solutions for problems that > very few real world systems want to tackle._

TBH, I think the problem is that people don't understand the value in linking our data silos through URIs; and so they don't take the time to learn RDFS or JSON-LD (which is pretty simple and useful for very important things like SEO: search engine result cards come from linked data embedded in HTML attributes (RDFa, Microdata) or JSON-LD)

The action buttons to 'RSVP', 'Track Package', anf 'View Issue' on Gmail emails are schema.org JSON-LD.

Applications can use linked data in any part of the stack: the database, the messages on the message queue, in the UI.

You might take a look at all of the use cases that SOLID solves for and realize how much unnecessary re-work has gone into indexing structs and forms validation. These are all the same app with UIs for interlinked subclasses of [https://schema.org/Thing](https://schema.org/Thing) with unique inferred properties and aggregations thereof.

> _In the intervening 2 full generations of tech development that have > happened since a lot of those standards were born, some of the underlying > stuff too (most particularly XML and XML-NS) went from indispensable to just > plain irritating._

Without XSD, for example, we have no portable way to share complex fractions.

There's a compact representation of JSON-LD that minimizes record schema overhead (which gzip or lzma generally handle anyway)

[https://lod-cloud.net](https://lod-cloud.net) is not a trivial or insignificant amount of linked data: there's real value in structuring property graphs with standard semantics.

Are our brains URI-labeled graphs? Nope, and we spend a ton of time talking to share data. Eventually, it's "well let's just get a spreadsheet and define some columns" for these property graph objects. And then, the other teams' spreadsheets have very similar columns with different labels and no portable datatypes (instead of URIs)

<comment><USER16> > Can you name a property graph use case that cannot be solved with RDFS and > SPARQL?

No - that's not the point. Of course you can do it with RDFS + SPARQL. For that matter you could do it with redis. Fully beside the point.

What's important is what the more fluent and easy way to do things is. People vote with their feet, and property graphs are demonstrably easier to work with for most use cases.

<comment><USER17> "Easier" is completely subjective, no way you can demonstrate that.

RDF solves a much larger problem than just graph data model and query. It addresses data interchange on the web scale, using URIs, zero-cost merge, Linked Data etc.

<comment><USER16> > "Easier" is completely subjective, no way you can demonstrate that.

I agree it's subjective. While there's no exact measurement for this sort of thing, the proxy measure people usually use is adoption; and if you look into for example Cypher vs. SPARQL adoption, Neo4j vs. RDF store adoption, people are basically voting with their feet.

From my personal experiences developing software with both, I've found property graphs much simpler and a better map for how people think of data.

It's true that RDF tries to solve data interchange on the web scale. That's what it was designed for. But the original design vision, in my view, hasn't come to fruition. There are bits and pieces that have been adopted to great effect (things like RDF microformats for tagging HTML docs) but nothing like what the vision was.

<comment><USER37> What was the vision?

The RDFJS "Comparison of RDFJS libraries" wiki page lists a number of implementations; though none for React or AngularJS yet, unfortunately. [https://www.w3.org/community/rdfjs/wiki/Comparison_of_RDFJS_...](https://www.w3.org/community/rdfjs/wiki/Comparison_of_RDFJS_libraries)

There's extra work to build general purpose frameworks for Linked Data. It may have been hard for any firm with limited resources to justify doing it the harder way (for collective returns)

Dokieli (SOLID (LDP,), WebID, W3C Web Annotations,) is a pretty cool - <USER2> deceptively simple-looking - showcase of what's possible with Linked Data; it just needs some CSS and a revenue model to pay for moderation. [https://dokie.li/](https://dokie.li/)

</comment></comment></comment></comment></comment></comment></comment><comment><USER36> Neo4j would become the standard while being far less used than Gremlin? This is nonsense isn't it?

<comment><USER21> Neo4j is by far used more than any other graph database out there. Regardless, the standard is not Neo4j specific. It was a collaboration from many companies in the space. They all agree it's a good move.

<comment><USER36> Well I've no statistics about tinkerpop vs neo4j and other usage, I may be wrong. But I know for sure that far more graph databases supports gremlin than supports opencypher. E.g the latest graph database from Microsoft [https://docs.microsoft.com/fr-fr/azure/cosmos-db/graph- intro...](https://docs.microsoft.com/fr-fr/azure/cosmos-db/graph-introduction) Also, Cypher has performance and expressivity issues.

<comment><USER13> Just looking at [https://db-engines.com/en/ranking/graph+dbms](https://db- engines.com/en/ranking/graph+dbms) clearly shows Neo4j as the most prominent graph db.

I think even Cosmos as number 2 might be misleading here, as Cosmos is a multi-model product and db engines doesn't distinguish between graph and non- graph use in the ranking. (Same for ArangoDB)

</comment></comment></comment></comment><comment><USER38> Hmm... There's this big, great, 'perfect', heavyweight graph query language (GQL) that is on process of standardized while an alternative (GraphQL) language is more readable (much more lightweight syntax IMO), has gained much more traction, etc...

While GQL and GraphQL's target is different(one is for interacting with Graph DBs while the other one is interacting with backends), there is a lot of overlap ongoing, and I just can't erase the feeling of the overlap between XML & JSON (where while XML was more 'perfect', JSON won the war).

Edit: Ok, GraphQL is insufficient for GraphDB Querying. Thanks for everyone's clarification.

<comment><USER39> GraphQL has nothing to do with graph databases.

<comment><USER38> Why? GraphQL is about modeling business domain objects in graphs [0] and querying them. Isn't that basically what Graph DB languages do too?

[0] [https://graphql.org/learn/thinking-in- graphs/](https://graphql.org/learn/thinking-in-graphs/)

<comment> frant-hartm It is a query language for APIs, name like RestQL or JsonQL would be much more suitable.

The expressiveness of GraphQL is severely limited, it doesn't allow you to express even simple patterns like triangles, depth n, paths etc..</comment></comment></comment></comment>


Eclipse PHP Development Tools Project Moved to GitHub - <AUTHOR> https://github.com/eclipse/pdt <comment><AUTHOR> I use Eclipse PDT for my own development because it's been the stalwart free- and-open-source PHP development platform. There are some other options now, but I've gotten used to it and I appreciate it's independent nature (just maintained by a dedicated team of enthusiasts) as opposed to a large company.

What I'm looking forward to the most is the future improved support for frameworks like Symfony, Laravel, and things like Blade templates and Facades (used by Laravel).</comment>


Ask HN: Convince me of a blockchain's utility - <AUTHOR> It seems to me that blockchains have no real value, and all of the potential applications of blockchain tech seem like they could be accomplished more easily and efficiently with a traditional database.
Part of my problem with blockchains is the premise - taken for granted by blockchain enthusiasts - that 'centralized data' is bad, and the salvation wrought by blockchains through 'decentralized data' is a major source of their utility.
First, data being controlled by a single entity is not a problem. In fact it promotes the curation and management of that data, which is a good thing.
Second, the concept of data decentralization, forgetting for a moment that it addresses a problem that doesn't exist, doesn't really make economic sense.
A data oriented business provides value by gathering and managing data that was not previously available. Ownership of that data and the associated promise of profit is the incentive necessary to motivate the work of gathering and presenting data in a workable format. No one who wants to build a data oriented business will ever want to 'decentralize' their data, because then they're basically giving up ownership.
Is my appraisal of the data (de)centralization issue correct? Why?
Where does a blockchain add real value? What does it enable that was not previously possible? How does it improve over existing solutions? <comment><USER2> I think the value may be more clear in the case of permissioned blockchains.

Imagine 5 big banks or 15 traders who meet around a buttonwood tree. In that case, having 5 or 15 copies of your database adds a lot of durability and tamper resistance.

1500 copies of the database, however, doesn't add 100 times the value of having 15. That's the trouble with blockchains. Before Bitcoin you would get laughed out of any distributed systems conference if you built a system that did not add workload capacity when you add more nodes. Right now you can do an ICO and score a cool $20 million.

</comment><comment><USER3> simple DMCA a bitcoin memo.

<comment><AUTHOR> ?</comment></comment>


Ask HN: To obfuscate or not to obfuscate Java bytecode? - <AUTHOR>

What is your take on bytecode obfuscation, specifically obfuscating a Java / Swing app that will have a trial version publicly available for download?
I know that obfuscation is not 'safe', and that there's always a way to decompile Java bytecode. But still, I have the feeling that I should do something to discourage enterprising users to decompile our code.
I have experimented with some Java bytecode obfuscators, and for whatever reason, they make the end result crash a lot. Now, I could probably dive into the inner workings of these obfuscators and somehow make it work, but it got me thinking: Does obfuscation actually make sense?
My thinking is that decompilation would be interesting to two groups of people: Those who want to crack the licensing mechanism, and the competition.
For the first group, I know there's probably nothing that will stop them. I have other means in place to discourage casual piracy, but I know there's no absolute security, and I don't plan to enforce that strictly (for the cost of unnerving paying users).
For the second group, my hunch is that it probably doesn't matter as well. If competitors can gain an advantage by looking at my (decompiled) source code, probably my business model is not robust enough, and I should rather be outperforming them, and stay ahead of the game.
What is your take on obfuscation? Does it make sense, and when so?
All your input is very appreciated!
Some background: We are working on a desktop application developed in Java / Swing, which is geared towards the enterprise market. Since the potential market is quite large and diverse, we want to make our app available as a trial version for download from our website. <comment><USER2> I think the goal of obfuscation should be to keep honest people honest. In the case of Java bytecode, I think they're _already_ honest. You don't see people casually decompiling bytecode, because it's a royal PITA and the resulting source is usually pretty unreadable anyway.

If someone really, really wants to reverse-engineer your object code, they'll find a way to. If it's important to your business that they not...I'd find a way to make it less important to your business.

</comment><comment><USER3> Obfuscation to protect source code, implementation details, etc. I believe is very rarely warranted. Most applications have fairly mundane implementations, with much of the differentiator being fit and finish of the whole. Even having the source code directly, rather than having to disassemble it, wouldn't be a huge risk IMO - any entity profiting from it will clearly be culpable of copyright violation.

It's easy to get paranoid about the value of source code. The fact is, most mature codebases are sufficiently scruffy that even their developers wouldn't want to start from that codebase if they were to create a competitor. And when you're not familiar with a body of source, it takes a lot of work to understand its architecture and how it's put together; so then the risk is even lower.

Obfuscation as a speedbump to cracking has more to say for it. If the obfuscation badly affects stability, I'd suggest only using it for a handful of core modules, code that lies on the critical path for most useful application uses. Obviously, it's important that the code isn't something trivial, like a boolean license check. It would have to be a module that would be non-trivial to reimplement and re-link into the application.

But of course I'd suggest other things, like baking in some kind of internet dependencies.

</comment><comment><USER4> If you can get it working safely, I'd recommend obfuscating. It's easier to remove it later than to add it when your full source is out in the wild. Getting the genie back in the box is impossible.

Yes, some will find a way to get at it, but there is no reason to make it stupidly easy for everyone else. Your competent competitors would probably rather write their own code than sniff through obfuscated code, but they might be quite happy to have your full source at hand when solving problems. Also, very little is stopping someone from simply lifting your code, making a few changes and releasing it as their own, for 10 bucks less than yours. It happens, I assure you.

</comment><comment><USER5> As an alternative, you might consider writing some portion of your app in a language that generates Java bytecode. Languages such as JRuby generate bytecode that _currently_ cannot be fully decompiled.

This is a little different approach as the bytecode code isn't mangled as an afterthought.

[http://jimlawless.wordpress.com/2010/03/07/jruby-as-a- java-o...](http://jimlawless.wordpress.com/2010/03/07/jruby-as-a-java- obfuscation-utility/)

</comment><comment><USER6> There are actually three ways other than obfustaction to protect your Java bytecode. I humbly suggest that you check out my article "Protect Your Java Code - Through Obfuscators And Beyond":

<http://www.excelsior-usa.com/articles/java-obfuscators.html></comment>


Scottish company Maidsafe claims to have built a Bitcloud-like system - <AUTHOR> http://www.wired.co.uk/news/archive/2014-01/27/maidsafe-bitcloud

<comment><USER2> Seems to be open-source: [https://github.com/maidsafe/MaidSafe/wiki](https://github.com/maidsafe/MaidSafe/wiki)</comment>


PressureNET - <AUTHOR> http://pressurenet.io/

<comment><USER2> Could you list the reasons for the app permissions you requires on the device? I see no need for you to access to the list of accounts on my device.

Also, I think it would be good to have an official "data policy". Sure, you're planning to make data available via S3, but does that only consist of barometer, location and timestamp?

<comment><AUTHOR> Thanks for the feedback! We do not need any account list, that's ridiculous. You can see our source code, here's the file that lists the actual permissions we request: [https://github.com/Cbsoftware/pressureNET/blob/master/Androi...](https://github.com/Cbsoftware/pressureNET/blob/master/AndroidManifest.xml)

You'll see the list includes READ_GSERVICES, which is for Google Maps. See here: [https://developers.google.com/maps/documentation/android/sta...](https://developers.google.com/maps/documentation/android/start#specify_app_settings_in_the_application_manifest)

Thanks for the note about the data policy, we'll get that online.</comment></comment>


Notch Is A Wearable Sensor & App For Tracking And Capturing Body Movements - <AUTHOR> http://techcrunch.com/2013/11/24/notch/

<comment><USER2> They may want to rethink their name, when you say Notch most people respond with Minecraft.</comment>


It Isn't a Game - <AUTHOR> It has consumed my existence trying to safely use and operate 2 MacBook MacBook Pros and iPhone 11ProMax in the last three months NOTHING will work to reset permission to delete hacker-modified folders. I am self-employed and work from home with extremely sensitive client data. I am completely fucked and I will never trust Apple now when I now I can't even delete a folder from my hard drive.
I'm going now but but it almost everything except "fascinating" to those of us laid flat out by this absurdly incompetent work by some guys who just think they are the absolute coolest at Apple.
Know that. <comment><USER2> nice</comment>


Humans see the world in higher resolution than most animals - <AUTHOR> https://today.duke.edu/2018/05/details-look-sharp-people-may-be-blurry-their-pets <comment><AUTHOR> [https://www.cell.com/trends/ecology- evolution/abstract/S0169...](https://www.cell.com/trends/ecology- evolution/abstract/S0169-5347\(18\)30052-1)

Visual Acuity and the Evolution of Signals

>Recent increased interest in visual acuity, the ability to perceive static spatial detail, has shown that acuity is highly variable, ranging over four orders of magnitude across species with image-forming eyes.

>Human visual acuity is some of the highest in the animal kingdom, meaning that researchers may develop hypotheses regarding the function of spatial patterns that do not account for the relevant viewer's sensory capabilities.

>Signals can potentially exploit differences in visual acuity between species, which may arise due to differences in eye type, eye size, and/or viewing distance.

>Because acuity can vary between two viewers of the same scene, it represents a promising yet understudied channel for private communication.

>Small animals, particularly those with compound eyes, have low acuity and thus can only perceive fine patterns over very short distances.</comment>


Stripe Apps - <AUTHOR> https://stripe.com/docs/apps

<comment><USER2> This is the first step towards the "marketplace" feature of WePay or PayPal, which is great. But it's not very useful unless I can add a fee for myself.

On a $100 purchase, I should be able to split the money so that $3.20 goes to Stripe, $1.00 goes to me, and $95.80 goes to the seller. Without that ability, I have to make up a separate billing arrangement with the seller, either a flat rate (eg subscription) or calculating fees and billing them post-hoc - messy and unreliable.

<comment><USER3> <https://stripe.com/docs/apps/fee-splitting>

<comment><USER4> does this solve the grandparents issue?

<comment><USER2> That does address the issue. Strange that the fee-splitting page doesn't seem to be linked from the documentation anywhere.

</comment></comment></comment></comment><comment><USER5> Check out <http://board.zapier.com> \-- a cool implentation of the API for a SaaS analytics dashboard.

<comment><USER6> Very cool :-) I just tried it for Buffer and the numbers were a little off, but love the thinking!

<comment><USER7> Yes, there a number of assumptions and simplifications made due to the easiest-available data from Stripe. Pull requests welcome: <https://github.com/zapier/stripeboard>

</comment></comment></comment><comment><USER8> Stripe is a pretty awesome company. Much more easy to integrate with compared to Paypal and their support blows Paypal out of the water.

</comment><comment><USER9> "Stripe works just as it normally would: we deposit the money into your users' bank accounts on a rolling seven day basis."

I can also use WePay, which deposits the money immediately and gives me a marketplace feature (I can take a chunk out of the payment for myself).

<comment><USER3> Stripe has fee-splitting. See my link above.

</comment></comment><comment><USER10> This is awesome. I definitely need to get it into <http://jungleblaze.com>

</comment><comment><USER11> Are there any apps out there right now? I don't think they list any in the application gallery.

<comment><USER12> <https://www.pay-pad.com/>, <http://shopify.com/> and <http://shoplocket.com/> are a few off the top of my head.

<comment><USER13> In addition to Pay Pad, we also have Alerts for Stripe: <http://www.pay- pad.com/alerts>

Also, Zapier open-sourced a nice dashboard that uses Stripe Apps: <https://board.zapier.com/>

</comment></comment></comment><comment><USER14> This has been out for a while now, I used it for a platform integration, really easy to use

</comment><comment><USER15> To part with $30 off a $1,000 payment. Way too much for me. Pass.

<comment><USER16> Paypal will take $29.30 if someone pays you $1000 and it isnt anywhere as easy to integrate (the pro non hosted version) and use as stripe.

Try and open a merchant account at any big bank and you wont get much better fees unless you are moving huge amounts of money.</comment></comment>


Ask HN: I want to cancel my Gmail. Alternatives? - <AUTHOR>

I'm now looking to cancel my Gmail account. What are my best alternatives? <comment><USER2> <http://news.ycombinator.com/item?id=1121269>

<comment><AUTHOR> Thanks. I didn't see that. Interesting that I'm not alone.

After they felt free to use my email contacts and frequency to seed their own social network, I feel I can't trust them anymore.</comment></comment>


Opera acquires Skyfire labs for $155M - <AUTHOR> http://mashable.com/2013/02/15/opera-acquires-skyfire-labs-for-155-million/

<comment><USER2> I never would have thought that Opera had $155 million to spend on an acquisition. Does their browser make any money?

<comment><USER3> I don't see how the desktop browser would make money, but Opera Mini is preinstalled on a large number of low-end devices. I imagine these bundling deals are quite profitable to the company, since Opera Mini is seeing a lot of use on those low-end phones.

Wikipedia has some recent numbers: "In February 2013, Opera reported 300 million unique Opera Mini active users and 150 billion page views served during that month." [1]

[1] <http://en.wikipedia.org/wiki/Opera_Mini>

<comment><USER4> The Desktop version gets payments from search vendors, Google pays significant sums to browser vendors to be the default search engine. But of course the bigger part of their income comes from the mobile.

</comment></comment></comment><comment><USER5> I submitted the original source 3 hours ahead of Mashable's rehash: <http://news.ycombinator.com/item?id=5224687>

</comment><comment><USER6> Congrats for Skyfire.

Knowing a few people there good to see them acquired by an interesting company. They've certainly changed a bit from the early days with the initial product being on WinMo (i was an early engineer there). The move makes some sense with Opera's embracing of WebKit.

I do agree with the other poster - opera had $155m? You learn new things every day.

<comment><USER7> It's suspicious, since nobody uses the browser. It's certainly unreliable in a work environment and the worst browser on the iPhone.

Sorry to be the wet blanket at this love-in, but maybe, just maybe Opera isn't what it appears.

<comment><USER8> Believe it or not, the rest of the world aren't all using smartphones. Opera Mini dominates the less-than-smart phone space.

</comment></comment></comment><comment><USER9> Does anyone have info on the Opera Unite story? I remember it being well received when it was announced but clearly it never gained traction. I see Opera have now canned it.

Perhaps a bit ahead of its time? In the next few years my country (.au) will be wired up with fibre to the home which makes this browser p2p thing more attractive. Also WebRTC seems timely.

<comment> andrewl-hn I joined Opera just before Unite was released. People told me that the idea was very old. They've been prototyping and re-working the product and were not 100% happy about it whet it was finally released.

It seems to me that at that time it would be a great idea to wrap the API into some mix of standards that emerged over time (IndexDB, AppCache, etc.) That way writing Unite applications would attract web developers interested in HTML5. It didn't happen and most web developers saw some proprietary API for a browser with a small marketshare. No wonder it didn't took off.

Something similar may appear on top of WebRTC like you suggested.

</comment></comment><comment><USER10> Busy week for Opera, a transition to WebKit and a big acquisition. I wonder if the Skyfire purchase indicates Opera is going to make a far bigger push to try and capture market share in mobile browsing, where at the moment there's far fewer competitors and an ever increasing marketshare to tap into.

<comment><USER11> Mobile can be way to capture desktop too. If you decide to use Opera on mobile, sync (Opera Link - <http://www.opera.com/link/> ) can convince you to use it on desktop as well.

I would especially love having sessions accessible on both devices. I believe it's not possible at the moment.

<comment><USER10> Nice point! That'd certainly have a draw for a lot of people, and I don't believe people have as much invested in their browser choice than they used too.

</comment></comment></comment><comment><USER7> Opera really needs to focus on their core product: the browser. Its truly lost its way. I uninstalled the desktop version a few months back because of it's so flaky and unreliable.

On the iPhone, it's being _blown away_ by upstarts like 360, Mercury and especially the slick Dolphin browser.

Chrome is still the best browser IMO, but like I said in an earlier comment, IE9 is surprisingly snappy. Stop being a snob and try it out.

As for Opera, can't truss it.

<comment><USER12> Is the desktop their core product? Or is the feature phone their core product? Opera Mini is big.</comment></comment>