willbudd

Right, yes. True. I should have compared with hardlinks instead.

Minor detail: I intended for different deletion semantics from hardlinks. Whereas hardlinks use reference counting for that (only the last deletion actually deletes); for my purposes, delete anywhere meant delete everywhere.

As a node in a tree hierarchy any folder can only have one parent folder. Tags of course allow nodes to have any number of parents (aka "associations").

The relationship between arbitrary nodes in a tree can be determined by tracing their common ancestry, but tags don't provide equivalent functionality, unless you strictly define how tags themselves relate to other tags. An obvious way to do so is to prescribe that every tag shall have exactly one parent (except for the root abstract "thing" tag).

In other words tags become folders, but any non-folder content of those folders can simultaneously live inside any number of folders. Similar to symlinks, but arguably less hacky, because there is no differentiation between "actual" location and "linked" location.

An interesting hybrid approach I've experimented with in the past is to use tags while ensuring that the tags themselves are purely hierarchical. (Is there a name for this scheme?)

Many of the big city centres in Japan are interconnected above and below ground at multiple levels just like that though. Umeda is a fun three dimensional labyrinth, for example.

I like the stdin/stdout idea from an ease of use POV, but doesn't having each connection in a separate process pose a rather significant constraint on scalability, considering also that WebSocket connections are generally considered to be long-lived?

char buf[255]; strcpy(buf, user_input);

I suppose that case can be made, but in this case the direct cause of the vulnerability is the WebSocket server not checking the HTTP Origin header in direct violation of the standard (RFC6455), which is spells out at that doing so is a MUST. I could maybe understand whitelisting localhost and file URLs, but giving a carte blanche -on every single interface no less- is just absurdly negligent.

Sounds to me like you (or Python devs?) should be looking at clone(), which is basically a lower level version of fork() that provides precise control over every detail with which the new process is created, including what (if any) parent memory you want to share.

The manual page is quite informative: man clone

Then compile it as a library, and dlopen() it after all. (I'm just guessing the gp's point was that JIT isn't really an essential modality.)

Oh, right. Fully agreed then.

Not sure what the context of your question is, but using Windows for the same purpose is probably doable too. It's just that Linux makes it a lot easier to ensure that your OS isn't any chattier on the network layer than it needs to be. I personally wouldn't feel comfortable trying to be an anonymous Windows user if the stakes were as high as we're alluding to here.

I don't think there was much "oh no, I didn't realize that yet" with Satoshi. He seemed to have been the epitome of meticulously planning/scheming things well in advance.

It's not that hard if you're careful. The last line of defence of using a well-chosen set of WiFi hotspots, auto-generated MAC addresses, and an otherwise silent Linux distro is pretty impenetrable even if all other proxy layering is somehow compromised.

Provided you're disciplined enough to properly containerize all ongoing sessions, of course. Careful planning is all it takes.

Yeah, I should have specified that I was referring to plain-old-data types such as integers. Custom objects overloading their operators certainly allow any number of differentiated rabbit holes to be dug.

You jest, but I always found it puzzling that there was a time (supposedly?) that compilers were dumb enough to assemble ++c and c++ differently in cases where they simply occur as stand-alone expressions, despite their obvious semantic equivalence.

Even stranger: people that insist on writing their (loops; like; ++this) in 2021 as if doing so is in any way superior or something.

Humans haven't solved driving either though.

I wrote something similar, except instead of providing a library (which Libwebsockets already does a fine job of), I created a server/framework accepting shared objects as backend plugins running as dedicated threads interacting with spsc lockless ringbuffers. In other words, more or less the inverse of a library: https://github.com/wbudd/ringsocket

I haven't been putting much time into it anymore lately, but I intend to create a bunch of language bindings for it soon so you can write plugins in other languages too such as Python, C++, Rust, etc. Should be interesting.

But nobody (as far as I know) who has used TypeScript wants to go back to vanilla JavaScript. I find that fairly telling.

I'd be inclined not to use the heap at all though in that case. Just preallocate static arrays in each location.

I think certain French revolutionaries found a more clear-cut solution a long time ago.

(Personally, I find the death sentence in any form barbaric, given how it nullifies any form of recourse in cases of wrongful conviction. It might however be an agreeable option to offer "voluntary execution" of some form: allow inmates convicted for life an alternative to using bedsheets in ways they weren't intended for. What a depressing topic, this.)

Imagine you have created a new social media webapp with a few innovative new features not seen elsewhere. Would that spell doom for a now suddenly inferior Facebook/Twitter/etc. Possibly, but the network effect in terms of inertia and critical mass makes that an unlikely proposition.

Moreover, the driving force behind Bitcoin keeping it ahead of the pack so far is the promise of short/medium term profit as an investment vehicle due to the artificial scarcity of its deflationary algorithm. Other cryptocurrencies are better positioned toward forming a long-term solution as a low overhead global decentralized payment platform, but what they offer is more of a collective benefit rather than a strong monetary incentive to any individual backer/investor on an individual level. (Which arguably is just an emergent property of human greed within the regime of unchecked capitalism.)

Whether or not you can pay/receive currency anonymously has nothing to do with whether or not you can contribute source code and/or whitepapers anonymously.

Those two statements capture perfectly what I think of Bitcoin too with its ridiculously deflationary block reward-halving algorithm.

Anyway, yes, I agree that 99% percent of existing cryptocurrency implementations are at least partially affected by short-sighted greed.

However, I think it's important to note that there is no technological constraint preventing the potential success of more egalitarian implementations. In that sense, it's at least disappointing to see technological potential for societal benefit being so categorically dismissed due to the flaws of early prototypes such as Bitcoin.

Ripple, Nxt, etc have been around since 2012-ish or earlier. Ancient technology, basically.

Proof-of-work =/= cryptocurrency. There are cryptocurrencies that work without proof-of-work, and those that quantitatively rely on it to a far lesser degree.

Honestly, it continues to surprise me how clueless most of HN commenters are on this topic.

> Open source developers across the world would like to have a chat.

I think this touches on an important aspect of working remotely: a high percentage of open source developers participate in these collaborations not because of financial reward, but because they are on some technical level passionate about the project(s) they are involved in. In other words, they find relatively strong intrinsic motivation in their endeavors in comparison to strictly external rewards such as remuneration.

Personally, I find that the presence/lack of such intrinsic motivation plays a far greater factor when working remotely than when I made hours at the office. In the office, social interaction and a clear-cut shift would compensate for otherwise intellectually unrewarding tasks, whereas at home the same kind of tasks often seem to turn into solitary mental struggles.

In other words, the freedom and efficiency of working remote can be wonderful, but I find it only tends to work out like when I'm (on some level) genuinely enthusiastic about the work at hand.

You have obviously no idea what you're talking about. Bitcoin's block mining algorithm is excessively deflationary: it encourages hoarding instead of spending while disproportionately rewarding early adopters. That however has absolutely nothing whatsoever todo with the blockchain algorithm, which was/is truly innovative as a decentralized ledger.

There is nothing preventing cryptocurrencies from utilizing blockchain technology in combination with inflationary currency generating models, and in fact plenty of them do. They are less well known partially because they were later to the game, and partially because they lack the get-rich-quick pump and dump appeal of bitcoin and co.

X as a display server is over three decades old, the popular incarnation in the nineties being XFree86, which devs abandoned in 2004 to form Xorg due to licensing issues. Most of the code itself really is ancient.

Just curious: how many companies have signed up to be with people that way?

Hopefully some word sense index is applied (or implied).