hp

13 ms·

61.
by hp 12y ago
That question is like asking "can you tell me something the Twitter API solves that http does not?" - it doesn't make any sense. They are distinct layers. One builds on the other. http+websocket is a way to set up a full-dupl
62.
by hp 12y ago
If I had touched any of this stuff in years I might treat it that way in part (after expressing annoyance), but I'm not currently involved - my ssh key probably doesn't even work anymore, but if it did I'd still go through th
63.
by hp 12y ago
Switching dbus to websocket/http instead of its own outer layer equivalent would get you about 1% done implementing dbus. It doesn't address or answer 99% of why dbus exists or what it does. So it's a fine thing to consider (
64.
by hp 12y ago
This probably deserves a long blog post or something (maybe I already wrote it somewhere) but here's a teaser. dbus is not mostly about IPC. Linux desktops, including gnome, KDE, and those before them and alternatives to them now, use
65.
by hp 12y ago
Why engage is a good question :-) I had the misfortune to see a link on Twitter and discover people were wrong on the Internet. I do think there's useful stuff to learn and discuss here about software development and dbus itself if peo
66.
by hp 12y ago
In creating dbus, I talked to a bunch of developers at KDE, specifically those who worked on Qt and DCOP, about their requirements. Then I met the requirements they said I had to meet for them to use dbus. I did the same for developers at G
67.
by hp 12y ago
I don't see the problem with having two protocols on one socket, as long as its defined how it works (how to switch over). HTTP for example supports switching to websocket. The spec has always said it was informal and needed more work,
68.
by hp 12y ago
I did stop, many years ago, in part because I was tired of this sort of thread. People who don't know the requirements and don't bother to learn anything go on ill-informed rants about other people's work. Hey, it's no l
69.
by hp 12y ago
Speed wasn't the right design goal for a mechanism used mostly for control purposes that simply didn't have to be fast. Least-common-denominator flexible implementation was the most important thing (threads or main loop, no depend
70.
by hp 12y ago
I created dbus and wrote the original spec. There is a nul byte first because some platforms require that to send credentials. Then a plain text protocol modeled on SASL for authentication. After that the binary message protocol begins. Sor
71.
by hp 12y ago
Here is the full context about the auth protocol in the spec: Authentication Protocol Before the flow of messages begins, two applications must authenticate. A simple plain-text protocol is used for authentication; this protocol is a SASL p
72.
by hp 12y ago
No. he's confusing the auth protocol with the dbus protocol.
73.
by hp 12y ago
Yes, there's an auth protocol before the actual dbus protocol - there are two protocols in the spec. I think that's what you are missing. Perhaps it's confusing but slow down and understand the tech before criticizing. It is
74.
by hp 12y ago
I think people who haven't hacked on making nice UIs for system features don't understand what problems these things solve. But people who have do, and that's why they code them. Is there a simpler, less-engineered way? Proba
75.
by hp 12y ago
No. It means everything is on-wire essentially the same as it would be in memory. Read the spec: http://dbus.freedesktop.org/doc/dbus-specification.html This article is essentially "I didn't understand someth
76.
by hp 12y ago
It isn't ASCII only, and I don't even see where the author of this article got that idea. Read the spec instead of the article and you'll learn more: http://dbus.freedesktop.org/doc/dbus-specification.htm
77.
by hp 13y ago
Scala doesn't have operator overloading btw. It just doesn't restrict method names very much. This is very different from how C++ treats operators as special cases. If you give your methods bad names, it really is not the language
78.
by hp 13y ago
The current direction we're hacking on is definitely toward shared code between Eclipse and other tools and editors.
79.
by hp 13y ago
the sbt point is really outdated; sbt 0.13 only ever requires you to use "foo := bar" (assign bar to foo), though one might choose to use convenience operators such as "foo += bar" (append bar to foo). sbt's syntax
80.
by hp 13y ago
https://github.com/scala/async is the syntactic sugar to write sequential nonblocking code in Scala (no callbacks). Though functional-style code works well also if you know it.
81.
by hp 13y ago
Scala has an `async`/`await` feature (like C#) now, which hides the Future ceremony and gives sequential syntax. https://github.com/scala/async I guess this does still require the `await` word, but I think it&#x27
82.
by hp 14y ago
VC funding is usually a decision to "go big or go home" on a timeframe, while bootstrapping allows you to continue indefinitely at any scale once revenues cover costs. Both have risks but the VC model is explicitly to spend at unsustainable
83.
by hp 14y ago
the config has arrays, it is a json superset. foo.bar = [1, 1]
84.
by hp 14y ago
Steve Jobs made the point nicely: "This stuff doesn’t change the world. It really doesn’t … Technologies can make it easier, can let us touch people we might not otherwise. But it’s a disservice to constantly put things in a radical new lig
85.
by hp 14y ago
Using flags in your visual design can be tempting but in my experience it's a bad idea. The problem is that certain flags force you to "take sides" in political disputes that you likely aren't aware of and don't understand. You'll inadverte
86.
by hp 14y ago
Insurance can't work if either all or none of your customers are going to file a claim, because the premise of insurance is that those who don't file claims pay for those who do. This insurance would have to charge a premium that would cove
87.
Desktop Task Switching Could Be Improved(blog.ometer.com)
1 points by hp 14y ago|0 comments
88.
by hp 14y ago
It makes total sense to omit comments, because JSON is optimized for machine-readability and interoperability (simple spec, simple implementation, no extension mechanism, fast to parse). Putting comments in would compromise it for that purp
89.
by hp 15y ago
I agree with basically everything Elijah has to say here for example: http://people.gnome.org/~newren/eg/git-eg-differences.html
90.
by hp 15y ago
I found that the syntax _was_ the hard part of git. That and the often-terrible man pages. Both docs and syntax are inconsistent, verging on random, and full of irrelevant details. It's pretty hard to figure out the actual concepts beneath

More ›