hp

The JSON superset aspect nicely supports spitting out JSON from a script when people want to do it that way.

HOCON is nice when for example you just want to sub in a couple of env variables or avoid a little cut-and-paste.

I wrote HOCON and also the above comparison post.

Here is my take on the why not JSON / why not YAML questions: https://blog.ometer.com/2015/09/07/json-like-config-a-spectr...

Short answer is "UX"

There's also a historical reason, Play Framework and Akka had both invented ad hoc formats, HOCON replaced both. The ad hoc formats added things like includes and substitutions but in regex-hack type of ways. So HOCON was cleaning those older parsers up with a single actually-documented format.

Though I don't see the point in reinventing your own build system, exactly. Some people I trust seem to be getting into Meson these days but I havent tried it.

This was the root cause, "a new desktop" presupposes the existing product category "desktop" which was a solved problem and a mature market. Runaway marketshare required NEW categories.

ABI compat and hardware support are hygiene features; they can slow adoption, but solving them doesn't motivate adoption. Linux needed the motivator; that would have then funded solving the hygiene stuff - just as it has, at least well enough, for x86 servers, Android, and Chromebook.

I don't say this with 20/20 hindsight either. I made this point loudly both inside GNOME and inside Red Hat back in the day. We even had chromebook-type proposals. But the Linux companies at that time were too small and server-focused to undertake such things, and once ipad/chromebook/android were out, there wasn't an obvious opportunity anymore for "Linux" proper.

Still, "Linux desktop" continues to work well for me and millions of other developers daily and I think it's very good for a dev workstation, as long as you buy hardware with OEM-developed open drivers (which mostly means Intel parts).

A lot of people who find it doesn't work for them are doing the equivalent of running OS X on non-Apple hardware with hacks to modify the finder, and surprise it's buggy. Granted, in the Linux world it isn't so clear what the "supported configuration" is. But think boring: default config of a major distribution with all open source drivers...

CC0 contains the lawyer-developed appropriate ceremony to do what you want here, including handling weird jurisdictions. The way you've phrased it will confuse the lawyers and may or may not "work" legally speaking.

There are instructions on the CC site about how to apply CC0 to a project. CC0 was developed for precisely this purpose.

The project could avoid the term "license free" and follow the guidelines for applying CC0 here for example: https://wiki.creativecommons.org/wiki/CC0_FAQ#How_do_I_apply...

The CC0 dedication itself is available in summary form https://creativecommons.org/publicdomain/zero/1.0/ and full legal form https://creativecommons.org/publicdomain/zero/1.0/legalcode

CC0's full legal form includes a "fallback license" in jurisdictions where public domain isn't permitted.

A piece of software can be public domain (which does mean you don't need a license to use/modify/redistribute it), or it can have a permissive license, or a choice of multiple licenses.

If "license free" means public domain, use the proper term, and use the suggested text from CC0 (written with a lawyer's help).

If "license free" means there's a choice of licenses, then offer a choice of licenses.

If something is not public domain, then "there is no license" normally means the default license, which is "all rights reserved" - everything is prohibited. For that reason, the term "license free" kind of implies the opposite of what this project intends.

Don't reinvent the legal wheel... especially when the CC0 dedication is already the exact thing you want to say.

Quite a few hash tables out there, and very complete standard-library-like utility libraries too. (aside: failure to use one of these is a major cause of bad, bug-ridden C code, containing for example calls to dangerous old-school string API from the standard library. If your C is of any size and you don't have a good string abstraction you are doing it wrong.)

There are lots of circumstances where I'd use something besides C, for sure. But if I was using C for a good reason, and needed a hash table, in most cases I would not write my own.

I'm probably listing the tip of the iceberg as far as network effects. In the Linux/Unix world, autotools is (or at least historically was) what everything and everybody knows how to deal with, and non-autotools is annoyingly nonstandard.

Your gyp link there says for example that its main goal is IDE support; a total non-goal for autotools. Unix/Linux C developers largely do not use IDEs. And the autotools goals probably aren't in gyp's list of priorities. So while they both "build the project" they have pretty different goals.

The autotools goals don't always make sense anymore. For example the historical idea that the shipped tarball would only depend on POSIX sh and not on any other binary made a lot more sense when people were hand-compiling stuff on their HP-UX than it does today where most binaries come from distributions.

If you're building a package mostly for Linux and maybe OS-X-as-Unix-compatible, especially one in C/C++ and open source, autotools probably still has a lot to recommend it.

That's why I think Rust is promising because "no GC" is often a reason to use C. You don't want two GC's that can see the same objects (unless you like leaks) so if you're writing code to be exported up into higher level languages, you don't want a language with GC.

It's also a LOT of extra code, really material bloat.

One experience I had doing this: http://blog.ometer.com/2008/02/04/out-of-memory-handling-d-b...

If you haven't written the test harness to test almost every malloc failing, you might think this is easier than it really is.

Adding 30-40% more code to your code base that will almost never get tested except maybe by your unit tests ... no thanks, not if it's possibly avoidable for a given application.

Or really, it isn't "context switching"; it's that there's the bus daemon in the middle which multiplies the userspace library overhead by 2, since messages are read and written twice as many times if you have the daemon in the middle.

Speeding up read/parse and marshal/write is completely separable from doing fewer read/parse marshal/write operations. Two different performance issues that aren't related as far as I can tell.

http://article.gmane.org/gmane.linux.kernel/1939651

kdbus is solving an "architecture" issue that would affect any binding, while his profile is essentially of the gdbus binding.

For a more in-depth performance discussion of dbus, check out http://lists.freedesktop.org/archives/dbus/2012-March/015024...

Above noted on linux-kernel here: http://thread.gmane.org/gmane.linux.kernel/1930358/focus=193...

What actually happened is that the high-level wrappers didn't get written for a long time because libdbus was just good enough that people didn't bother to work on alternatives. So that sucked, but it does seem to have finally been sorted out and libdbus is now on the way out AIUI.

http+websocket is a way to set up a full-duplex stream of messages where messages are anything you like.

dbus does have that part, but then it defines additionally what the messages actually look like in enough detail to bind them to method calls; it defines semantics such as guaranteed ordering and errors; it defines a central bus daemon; it adds broadcast messages over the daemon; it adds security features to allow mixing user and system domains; it adds a way to locate the bus daemon; it adds a way to launch and track the lifecycle of named processes; etc, a number of other APIs. It is not just a socket.

Could you implement a dbus-equivalent using http? Sure. But http does not include a "free" implementation of dbus, any more than it includes an implementation of Twitter.

dbus-on-http would have to define how method signatures and types map into http, and then it would still have to actually implement the daemon with its features and semantics.

http wouldn't make any material difference here; it would have some bikeshed-level pros and cons, but not change the system design in a material way.

The current people doing this kind of work deserve non-abusive informed criticism. It isn't OK to post a long diatribe of BS and then expect people to take it as if it were a helpful bug report. It isn't helpful. It's jackassery and unacceptable and this kind of abuse has done more damage to Linux than anyone knows.

It is entirely OK to ask questions or file bugs without sending patches. Just don't be an ass about it like this article was.

So it's a fine thing to consider (since websocket exists now) but I'd question the word "just" here.

It's like saying the way you'd implement an Amazon web service would be to "just use http." OK. Now what is the service? ;-) I hope that makes sense.

It's a mistake to view the problem solved here as "sending messages." The problem is all about the semantics of sending them and the lifecycle services provided by the central daemon.

dbus is not mostly about IPC.

Linux desktops, including gnome, KDE, and those before them and alternatives to them now, use a "swarm of processes" architecture. This is as opposed to an alternative like smalltalk, Eclipse, Firefox, or Emacs where lots of plugins are loaded into one huge process.

Problems common in server side IPC which aren't as big an issue here: scalability; network partitioning; protocol interoperability.

Problems which are more of an issue: service discovery (can't just use DNS); tracking lifecycle of other processes; inherent singleton, stateful nature of hardware, the kernel, and user interfaces.

The main way dbus helps with this is the star topology with a daemon that can start on demand and track all the processes. IPC is then coordinated with this in such a way that race conditions can be avoided, for example you can start a service and send it a command without a race that your command arrives too soon.

Anyhow this is just enough to get an interested person tracking down the details, I'm not spelling it out obviously.

I do think there's useful stuff to learn and discuss here about software development and dbus itself if people dig in and understand it. Perhaps some bystanders will learn something.

I welcome improving and even disrupting and replacing dbus but I don't think the kind of criticism found in this article will lead to that.

There was no mechanism to strongarm anybody into anything. KDE and GNOME devs told many ideas and many people to take a hike over the years. dbus was simply a matter of figuring out what those developers wanted and focusing on solving the actual problem, rather than hypothetical or philosophical problems.

When dbus was adopted, remember, people had already been down many roads; ad hoc IPC mechanisms, ad hoc communication through files and timestamps, hacks over X11 protocol, DCOP, multiple implementations of CORBA, SOAP, ICE (the old X-associated one), etc. People had wrestled with this problem space a lot and they had some pretty developed ideas about how to do things ideally. dbus was about coalescing those ideas into running code, and that was successful and stuck for a decade-plus now.

People sometimes have a "wtf" reaction coming from Internet protocols or kernel concerns, and while there are some wtf-worthy details in any piece of software, lots of the time people just don't understand the problem. Just as GNOME and KDE both took years to understand it and flailed around with all those protocols that didn't work out well.