1. 3

    tl;dr in 2019, Figma switched from running plugin JS in the “realms shim” to using the QuickJS interpreter by Fabrice Bellard compiled to WebAssembly.

    I was inspired by this post to build my own Emscripten wrapper around QuickJS: https://github.com/justjake/quickjs-emscripten You can use it to sandbox and evaluate Ecmascript 2020 code on the web or in NodeJS.

    1. 1

      I think using something like bdd-lazy-var (https://github.com/stalniy/bdd-lazy-var) is both more ergonomic and more type-safe, and they tend to be more performant than imperative setup/teardown code because cases that don’t consume a fixture don’t pay for it. I wrote a typescript wrapper that also takes an optional destructor, so the entire fixture declaration is a single call to lazy.

      @gregb did you consider using the test runner instance (“this” in mocha) as your context object? More magical but requires less boilerplate. I like boring code, but will allow for magical test frameworks if they increase the probability people will wire tests.

      1. 12

        I backed for one of the second-generation Atreus boards, but you can also build your own first-generation right now.

        Tiny, “split”, ergonomic/ortholinear, mechanical, hackable. Really looking forward to getting it.

        1. 7

          (Atreus creator here) Thanks! I was just talking on #lobsters IRC about how I was working on a new scheme-based firmware for this that’s been a lot of fun: https://git.sr.ht/~technomancy/menelaus/tree/master/menelaus.scm

          Figured folks here might find that interesting. It’s fully functional in about 300 lines.

          1. 3

            It’s crazy how simple that is compared to some more popular firmwares written C… Lovely work as always

            1. 2

              I just backed - not sure if I’ll end up converted from my Kineses Advantage, but I sure would like a portable option :)

              1. 1

                That was definitely the original intent; it was designed to complement a larger board for when you’re away from your desk. (That said, I stopped using my larger board once I got used to it.) Enjoy!

            2. 2

              Also, a proud owner of Atreus here. I can say that assembling Atreus was a fun exercise, it’s a compact and very ergonomic keyboard. My touch typing on Atreus is still slow (and even slower when I type in my native language) after I switched from Pok3r, but I enjoy using it.

            1. 9

              Something to keep in mind when talking about performance is that JSON is very very fast in the browsers, and would be hard to beat for that use case. It would be interested to compare with a WASM MsgPack decoder.

              1. 5

                MessagePack has a couple benefits over JSON even if the parsing was not as fast. Constructed properly, it’s smaller than even compressed JSON, and it’s substantially better for streaming because it has length-prefixed sections (length in terms of number of items, not in terms of bytes) – in other words, it is possible to process and generate streaming msgpack without much caching and without storing much state.

                Unfortunately, most implementations don’t actually support streaming, but bitbanging msgpack is almost as straightforward as constructing json with string manipulation & implementing your own msgpack parser is a hell of a lot easier than parsing json, so needing to roll your own msgpack implementation (while it may look intimidating) is no barrier to even a novice developer.

                1. 1

                  Is this because it can be loaded in as a native object without writing a parser for it in JavaScript? That comes with its own problems

                  1. 2

                    No need to load as a native object. JavaScript has had a (native) parser API for ages (JSON.parse(), since IE8)

                    1. 1

                      If you trust the source, the javascript parser is (much) faster.

                      Yes, I am aware of how ridiculous that sounds.

                      No, I don’t know why.

                      Yes, I have benchmarked it.

                      No, I don’t still have the results.

                      1. 2

                        On what JavaScript VM, for what data size, on which platforms did you find this to be true?

                        Chrome recommends embedding large constants as JSON to speed up parsing executable JS: https://v8.dev/blog/cost-of-javascript-2019#json

                        But, they’re discussing JS parsing at app boot time, not deserialization.

                        1. 1

                          This was ~10 years back, so my memory is imperfect, but we were primarily targeting Firefox and also testing IE. A megabyte or so of JSON, with lots of multi-kilobyte string values.

                1. 1

                  Off topic, you may want to run a spell checker over your posts.

                  On topic, yes, this is annoying!

                  1. 3

                    Thanks, I’ll run one on it and make some corrections. I wrote it in vim, in which I’ve still not found a good spellcheck workflow.

                    1. 10

                      What’s wrong with the built-in :set spell?

                      1. 1

                        I set F3 to toggle spell check on and off, it really helps me keep it off except for spell checking passes.

                  1. 1

                    I’ve been lately thinking about adding search to some documentation servers we have at work, which are essentially serving static content produced from a bunch of asciidocs.

                    Both stork and tinysearch could be useful for that task, as we could hack somehow which plaintext goes into which page. However, I have a feeling it would introduce a big overhead with pushing unnecessarily (for our use case) all the indexes to the clients, where we actually control the web server, and could run a search process there. Are there any tools for the use case where one has a static site, but also controls the webserver? I would like to avoid elasticsearch, but I’m not aware of any other.

                    1. 1

                      This is probably the best time to send indexes to the client! Your business probably provides decent machines to developers/doc users, as well as a good uplink to wherever the docs are hosted!

                      For an example of a client-side search system that works well, check out mkdocs. Mkdocs is a static site generator written in python that includes lunr.js client-side indexed search; see the docs here: https://www.mkdocs.org/user-guide/configuration/#search

                      I built the engineering documentation system at Airbnb on mkdocs with a hybrid search model, here’s how it works: Each project generates a standard mkdocs static site. The build outputs a bunch of HTML files as well as an index.json which contains flattened, stopword-processed plain text that’s very easy to index. When a project’s docs are deployed, this build output gets pushed up to S3 for static serving. Inside a single project we used mkdocs’ build-in search feature to search that index on the client.

                      There’s also a small node.js server that enumerates all the projects and pulls all the index.json files for each project into memory and combines them into a single lunr.js index. The server handles top-level queries when the user isn’t sure what project they need to look at. Lunr.js and S3 are both fast enough that the server process can re-fetch and re-index any changed index.json content as part of servicing a search request - at least, for the ~100ish projects that changed docs ~about 10 times a day. Search quality was probably lower than you’d get with Elasticsearch, but the simplicity of the system was well worth it - I made this whole system happen in hours instead of the days or weeks it would have taken to magick up a cluster, figure out all the fiddly elasticsearch bits, etc.

                    1. 2

                      I would be interested to see a comparison to the performance of other in-browser search index schemes, like lunr.js, flexsearch, fuse.js

                      (@jil you might want to check your homepage design in WebKit browsers - on my iPhone 10 a lot of text was off the edge of the screen with no way to fix it!)

                      1. 1

                        Coming in kinda late, but just fixed the text on the site. Thanks again for alerting me.

                        1. 1

                          Same on Firefox Preview (Android)

                          1. 1

                            Oh no! Thanks for letting me know. I had fixed a layout bug everywhere else… and must have accidentally borked things on mobile.

                            CSS is frustrating sometimes.

                          1. 2

                            My spontaneous reaction is “meh, 5.3”. And yes, that’s the latest version, but as long as the upstream Lua is so slow compared to LuaJIT, the LuaJIT version is the important one for me and a lot of other people.

                            1. 8

                              Considering the application to a boot loader, I think in this case it’s understandable to prefer the slower, simpler interpreter - remember this environment is so simple that it doesn’t attempt to support floating point.

                              1. 3

                                Looks like this is intended to scipt some things for the bootloader. Just curious what you’re particular application of luajit is?

                                1. 2

                                  LuaJIT doesn’t seem to be maintained anymore. The last official release is 2.1.0-beta3 from 2017-05. And only this beta supports newer architectures like aarch64. There are several forks of LuaJIT now but.. OS distributions aren’t exactly happy about random forks, are they?

                                  Plus, there’s no need for JIT performance when what you’re replacing is shell, an embedded Forth, VimScript…

                                  I always prefer upstream Lua because I don’t do high-performance things and I wish LuaJIT didn’t divide the ecosystem by sticking to an old language version >_<

                                  1. 1

                                    I see what you’re saying and I handwaved all LuaJIT forks away and should’ve said “LuaJIT etc. (Raptor looks good so far) - and I know as much as the next person that languages shouldn’t just stagnate but are evolving. But as someone who has only ever used Lua either “embedded” as a scripting language or deployed in an appliance-like setting (it won’t be touched or upgraded except security fixes) I really don’t need any progression and want stability. Lua on its own is a nice language, but if it’s so slow it’s not helping me. For (and this probably unfair to the Lua team) since LuaJIT was on the market, that’s what I wanted to use. It’s more upstream Lua’s fault for not being as fast, not LuaJIT’s fault for being unmaintained. And yes, this is close to a fork situation, but for me it’s clear on which side I am.

                                1. 3

                                  My company has always been highly dependent on the Amazon ecosystem. When we made the move to a microservice architecture three years ago, we opted for Amazon ECS as it was the simplest way to achieve container orchestration.

                                  With new business constraints, we have to migrate from Amazon to a different cloud provider, breaking away from the Amazon ecosystem, including ECS. We are still a relatively small company and cannot afford to spend months on the infrastructure instead of focusing on delivering on the business front.

                                  Articles such as this one are a good reminder that Kubernetes is still not an easy solution to implement, and some of the comments confirm my assumption that upgrading and maintaining a Kubernetes cluster can be challenging. It’s a tough call since it’s also the most popular technology around, which helps with recruitment. The absolute certainty is that we no longer want to be tied to a cloud provider, and will choose a technology that allows us to move more freely between providers (no coupling is nothing else than a dream).

                                  1. 5

                                    I’d recommend checking out Hashicorp Nomad[0]. It’s operationally simple and easy to get your head around for the most part. A past issue of the FreeBSD Journal had an article on it [1].

                                    0: https://nomadproject.io/

                                    1: https://www.freebsdfoundation.org/past-issues/containerization/

                                    1. 2

                                      I love Hashicorp. I’ve yet to encounter a product of theirs that didn’t spark joy.

                                      1. 2

                                        I’ve talked to more teams switching away from Nomad to Kubernetes than I have talked to people using Nomad or considering Nomad. A common Nomad complaint I hear is that support and maintenance is very limited.

                                        I’m interested to hear any experience reports on the product that suggest otherwise - My team runs on Beanstalk right now, but I miss the flexibility of a more dynamic environment.

                                        1. 1

                                          I assume if you are willing to pay the $$$$$$$$$‘s for the Enterprise version, the support is fabulous. If it’s not, one is definitely getting ripped off. I have no experience with the enterprise versions of any of Hashicorp’s products, we can’t afford it. We also don’t need it. We went in knowing we would never buy the enterprise version.

                                          We haven’t had any issues getting stuff merged upstream that makes sense, and/or getting actual issues fixed, but we’ve been running nomad now for years, and I don’t even remember the last time I had to open an issue or PR, so it’s possible things have changed in that regard.

                                        2. 1

                                          It is indeed one of the alternatives that we have been looking at. My only concerns about Nomad (and Hashicorp products in general) are the additional cost once you use the enterprise features, the smaller candidates pool (everyone is excited about Kubernetes these days), and the absence of load balancing.

                                          1. 2

                                            Both Traefik and Fabio works as an ingress load balancer on the (nomad) cluster. We use the Spring Cloud Gateway as our ingress.

                                            For service to service communication you can run Consul (we do this)

                                            1. 1

                                              Seconding fabio as an incredibly simple automatic ingress, and consul service discovery (-> connect+envoy) for service to service. There’s a nice guide as well https://learn.hashicorp.com/nomad/load-balancing/fabio . I’d consider nomad incomplete without consul and vault, but i’d also say the same (particularly vault is irreplaceable) for k8s.

                                              As for hiring – hire the k8s candidates. They’re both omega schedulers so the core scheduling concepts and job constructs (pod <-> alloc, etc) translate well, and I’d wager for some k8s veterans not having to deal with a balkanized ecosystem and scheduler wordpress plugins (CRDs/operators) would be seen as features.

                                              docker itself is by far the weakest link for us, but nomad also offers flexibility there.

                                            2. 1

                                              My suggestion is just make sure you don’t need the enterprise features :) You can get very far without the enterprise $$$$ expense, that’s what we do. But agreed, the Enterprise version for any of the Hashicorp things are very very expensive.

                                              Load balancing is easily solved as others have said. We use HAProxy and it lives outside of the nomad cluster.

                                              Agreed, everyone is all excited by k8s, because everything that comes out of Google(if only the design) must be perfect for your non-google sized businesses. Let’s face it, the chances of any of us growing to the size of Google is basically trending towards zero, so why optimize prematurely for that?

                                              The upside for the candidate pool being “smaller” is you can read through the Nomad docs in an hour or so, and have a pretty good idea of how everything works and ties together, and can be productive, even as a sysadmin type role, pretty quickly. IME one can’t begin to understand how k8s works in an hour.

                                        1. 3

                                          The main workflow we use: every feature or fix is initially worked on in its own branch that diverges directly from master.

                                          A branch is ready to merge when ci passes, commits represent isolated change sets, commit messages are descriptive and peer reviewers are satisfied.

                                          In the peer review process, adapting earlier commits in the feature branch after pushing and receiving feedback is encouraged. And thus force pushing is common practice.

                                          Then 1) rebase to master and 2) merge back to master without fast forwarding. A github bot makes sure that only one merge can happen at any time and that a branch is rebased to master one last time before it is merged. This results in a very simple, linear graph, but all commits from a single feature/fix branch stay visually grouped.

                                          EDIT: The master branch represents a big future release of the product, which is not the public version. The latest public version and legacy versions are in their own branches, and hotfixes follow the same pattern as in master, except that the fix branches derive from the version branch.

                                          Changes on master can be cherry-picked into the public versions branches if needed. Hotfixes on the public version branch are merged into master on a weekly basis as a single, squashed commit.

                                          1. 3

                                            I can highly recommend to consider using something like https://bors.tech for this workflow. It makes sure the merge commits are meaningful (“merges this branch, ticket here…”) and has a merge model that makes it frictionless.

                                            1. 1

                                              This is great to see in the wild. My team had to build the merge queue feature and it was a huge pain to orchestrate and keep devs happy.

                                              1. 1

                                                It’s an extraction of what Rust uses for rust-lang/rust.

                                            2. 1
                                              1. rebase to master and 2) merge back to master without fast forwarding.

                                              This results in a very simple, linear graph,

                                              If every commit has exactly one parent, what difference does it make if you’re not fast forwarding? You get, what, a … merge commit that has just one parent and no content?

                                              1. 2

                                                The merge commit can hold quite a lot of metadata - who reviewed it, where can I find the documentation for what was merged (Issue, PR number), etc. Merge commits are only junk if you don’t care about editing them.

                                                1. 2

                                                  merge commit that has just one parent and no content?

                                                  Exactly. This way, the information of which commits were done together within a branch is not lost. In our case the merge commit message usually holds the description of the pull request.

                                                  1. 1

                                                    oh, I just put that stuff in an annotated tag. The commits you’re talking about are just the commits between the two tags. Then I use git diff thing-v0.3.2 thing-v0.3.3 or git log thing-v0.3.2..thing-v0.3.3. The urls you get out of bitbucket or github then have the tag names instead of commit hashes, so the urls actually describe whats on the page. Um, I’m pretty sure every benefit that people have mentioned works the same with annotated tags?

                                                    1. 1

                                                      That seems like a good approach too. The only thing is that you don’t get is the nice graph in a GUI git client: one line representing master and single offsprings getting grouped back in.

                                                  2. 1

                                                    Merges with two parents, but one of the parents is a descendant of the other.

                                                  1. 3

                                                    Yes, with exception that instead of “version branches” create branch for release, prepare it there, tag release, then merge it to the master and call it a day, no develop/master split and having each commit on master tagged.

                                                    1. 6

                                                      Using tags only for web-only/evergreen software can work, but branched versions are often a must-have for desktop work. If a security issue is discovered with version 1.3.0 through 1.6.7, you may need to release 1.3.1, 1.4.6, and 1.5.3 alongside 1.6.8. In that world, it’s best to have 1.3, 1.4, 1.5, and 1.6 branches, where e.g. 1.4.5 is a tag on the 1.4 branch. In this scenario, you’d want to fix the bug in the 1.3 branch and cut a tag, then merge that into the 1.4 branch and cut a tag, then merge into the 1.5 branch and cut a tag, etc. That workflow’s not doable using just tags.

                                                      Again, for evergreen/web-only software, I’m with you, but version branches absolutely have their place.

                                                      1. 3

                                                        But you know that you can create commit on detached head? You do not need branch for that? And even then you can create temporary branch for that particular fix, ex.:

                                                        git checkout -b hotfix/space-overheating v1.3.0
                                                        

                                                        And after that you can create new tag 1.3.1 that will not be reachable from master (as you would do anyway) and you can remove temporary branch.

                                                        1. 1

                                                          I would not say “must-have”, I believe google chrome is doing just fine with a continuous release model, even though it is “desktop work”: https://medium.com/@aboodman/in-march-2011-i-drafted-an-article-explaining-how-the-team-responsible-for-google-chrome-ships-c479ba623a1b

                                                          1. 4

                                                            I’m aware of that, which is why I also very clearly, twice, called out evergreen software as also not needing branched versions.

                                                            1. 1

                                                              I wasn’t aware of the term “evergreen software” is there a definition around somewhere?

                                                              1. 1

                                                                I’ve heard it used informally to refer to, for example, an API that is continously updated without a specific version number. Breaking changes are communicated by other channels, such as websites for developers.

                                                            2. 2

                                                              Google has the ability to say ‘this software is only supported for 6 weeks and then you must update’. 99% of other software vendors do not have that ability.

                                                              1. 3

                                                                Software Users have been burned by vendors too often, that is why they demand “bugfix releases”, they do not trust devs to deliver a feature upgrade without regressions.

                                                                1. 2

                                                                  I mean it’s not like people trust Google to deliver a feature upgrade without regressions. They just don’t really get any say in it. Google’s web browser isn’t a product.

                                                        2. 2

                                                          I don’t understand what branch by abstraction is about. From the web site, it seems like a development strategy, rather than a way to use version control.

                                                          1. 1

                                                            They go hand in hand:

                                                            • Don’t do long lived (>1 week) branches, especially don’t do them to build large new features.

                                                            • Instead, use a well-conceived feature-flag system to turn off in-progress code that you merge to master.

                                                            It’s a negative suggestion, not a complete version control strategy.

                                                        1. 5

                                                          The Odin conversation from the orange site was high quality in this thread from 30 days ago. Sometimes lobsters have mixed reactions about links yonder but in this case the thread was nice so I’m gonna post it: https://news.ycombinator.com/item?id=22199942

                                                          1. 10

                                                            I love the look of these error messages. As someone who doesn’t use Erlang ecosystem at all, I’m interested in trying this language out because these look so inviting! Great work.

                                                            1. 2

                                                              Thank you for your support! :)

                                                            1. 5

                                                              If packagers are patching Discord to put Discord into a Flatpak or Snap, then it’s on those same packagers to patch this update dialog. It’s the same separation of responsibility between any upstream and a distributor: the distributor is responsible for their patches! How can upstream be anticipate 3rd-party, downstream changes?This is a bug in the Flatpack/Snap package.

                                                              As an aside, this kind of reaction is why my $DAYJOB doesn’t package our Electron app for Linux - we’d rather not deal with this kind of feedback where the true responsibility of support is diffused between our company, the OS maintainers, PPAs, etc, but we end up taking heat from takes like this. You can use our product just fine in Firefox and leverage all the browser’s well-known tools for privacy and customization.

                                                              1. 6

                                                                Discord isn’t patched, its packages are simply installers for the tarball using the chosen system.

                                                                Discord is closed-source software, it can’t be patched that easily.

                                                              1. 7

                                                                I have mixed feelings about this. No longer mixed because of how yeah, this just seems very disrespectful.

                                                                Mostly, it can be summed up as “can you just not?”

                                                                This project is famous because of why it came to be, and who created it. It was the result of Terry’s mental illness which was also the unfortunate cause of his death. Trying to piggyback on it feels incredibly disingenuous and almost disrespectful, especially given the circumstances around its creation.

                                                                Let it rest with Terry.

                                                                EDIT: I completely forgot about that description - “A TempleOS distro for heretics” - this just sounds incredibly disrespectful.

                                                                1. 25

                                                                  Trying to piggyback on it feels incredibly disingenuous and almost disrespectful, especially given the circumstances around its creation. Let it rest with Terry.

                                                                  I think that on contrary, we should use, study and think about the lessons Terry gave us in form of the Temple OS. There is nothing disrespectful in trying to build on his legacy.

                                                                  1. 16

                                                                    I agree - Terry didn’t take his software with him to the grave - he shared it with the world and made it public domain.

                                                                    1. 9

                                                                      Gotta agree here as well. I can appreciate that great care should be taken to give proper respect to the nature of his illness and personal circumstances but that said I think his work has a LOT of interesting technical details that could be studied and might inspire others.

                                                                    2. 14

                                                                      So in your opinion, Terry’s work should just be left to wither and die, out of respect for him. Would this be true if he hadn’t been mentally ill? Would it be true if he hadn’t died?

                                                                      You assume the author of Shrine has forked TempleOS to acquire fame. What if he didn’t?

                                                                      1. 10

                                                                        It was released before Terry’s passing

                                                                        1. 1

                                                                          That doesn’t change much.

                                                                          1. 5

                                                                            Sincere question here - should the entire work product of someone who became mentally ill and whose work might potentially contain some aspects which were a product of delusions they experienced as a result be excluded from future scholarship out of respect?

                                                                            (The answer may very well be yes - I’m just trying to understand the point you’re making.)

                                                                        2. 7

                                                                          I’m confused here that this is upvoted so high. Why is it disrespectful? It’s public domain fork of a public domain project. Why do people need to be so uptight about everything?

                                                                          1. 2

                                                                            I’m absolutely in favor of studying TempleOS, it was clearly meant for that. Just, yes, this particular approach does seem intentionally disrespectful. It’s a matter of opinion; I certainly won’t try to stop them from doing that, but that’s my opinion.

                                                                            1. 2

                                                                              It was the result of Terry’s mental illness

                                                                              I think it is a result of Terry’s genius and mental illness. And projects like this that make it easier to utilize and explore Terry’s great work.

                                                                            1. 5

                                                                              Using serialization and de-serialization to mungle object keys is a horrible idea! Not only will it be much slower, and allocate much more than a structured-clone, it also introduces all these value rules you need to keep in mind!

                                                                              I’d much rather see a recursive clone solution than JSON-and-Regexp.

                                                                              1. 1

                                                                                The intention of this defaults-heavy API is to make rapid development of simple apps both easy and correct. Look at that list example - looks great! In both cases. On the web with resets, no two implementations of that pattern are going to look the same.

                                                                                Yes, these defaults will bamboozle sometimes. The framework should provide a contextual way to disable them in a subtree when you are doing something specific, like NoDefaults {Custom(); Weird(); Layout() }

                                                                                1. 29

                                                                                  I don’t think there’s anything Urbit can do or say to erase the history of Yarvin or my overall impression that they’re building “digital share-cropping” from Yarvin’s ideals.

                                                                                  1. 5

                                                                                    I neither have a slightest idea what Urbit is, nor Yarvin. But the visuals in the article look interesting to me.

                                                                                    Personally, I actually most like the 2nd set of images in the Experiments + iterations section. They seem to have most visual difference between them, compared to all the others, in my eyes. I’m very curious what was the algorithm behind them.

                                                                                    1. 8

                                                                                      Agreed - this article is so precisely up my alley but I wish it had come from anywhere else

                                                                                      1. 10

                                                                                        In 10 years I believe this is the only imprint Urbit will have left behind.

                                                                                      2. 14

                                                                                        Haters gonna hate. But on Lobste.rs, I expect better quality comments. This is about on the level of commenting “but Google’s so bad” on a Google product team’s tech blog, with no reference to the actual content. It’s low-effort, and needlessly negative.

                                                                                        Even someone who is politically or philosopically opposed to Urbit’s structure can learn something about generative graphic design from this post. I found it pretty thoughtful myself. It’s a small but meaningful problem they’re taking on here.

                                                                                        Sad thing is, I expect this comment to get downvoted by approximately the same users who upvoted yours, for the same essentially political reasons. So let me be clear: I’m just speaking up for civil, technical, on-topic discussion. I’m not expressing any opinion about Urbit’s system design or history, and I’m not even slightly interested in rehashing that tired topic here.

                                                                                        1. 17

                                                                                          I upvoted the article, which I found interesting and the art therein beautiful. But does saying that count as a high-effort comment?

                                                                                          There’s a difference between leaving a comment on Lobsters rehashing Google, a widely known company with a long public history, and leaving a comment about an obscure start-up. In both cases, you are familiar with the subject, but for many here, they may never have heard of Urbit before. I guess an analogy would be “knives don’t need warning labels, but odorless deadly chemicals do”.

                                                                                          1. 3

                                                                                            Or, you could just Google “urbit”, and find as much drama as you can stomach. Without wanting to get into how “deadly” it is, I don’t agree that it’s “odorless”.

                                                                                          2. 4

                                                                                            Thank you for this comment. The main reason I prefer Lobsters to HN is the general absence of politics, and a clear focus on technology. I hope it stays that way.

                                                                                            1. 3

                                                                                              Urbit is a politically motivated technology, so why is it allowed on this site then?

                                                                                          3. 7

                                                                                            Yeah its certainly some kind of scam. What specific kind of scam will be more obvious as it plays out but nothing good comes out of trying to model feudalism.

                                                                                            1. 1

                                                                                              Are you really sure about that? Last century was very democratic and very very bloody.

                                                                                              In the old days, the winners turned the losers into serfs. At least that was somewhat productive, and there were periods of peace between the conquests.

                                                                                              The modern approach is to napalm and drone-strike relatively harmless peasants–perpetually and fruitlessly–so that corporate and military bureaucrats can justify their paychecks.

                                                                                              Also, it is highly debatable whether the disparity between a modern-day oligarch and an ordinary joe is any smaller than that of a 16th century noble and his peasants.

                                                                                              I don’t see a clear winner here.

                                                                                              1. 2

                                                                                                There’s countries where you can try out a feudal system today if you think that’s comparable. Somehow I suspect your opinions will shift when you go there and see that it’s a human meat grinder. You might think that you would be the lord, but I can assure you that you would be a serf unless you are particularly talented at murder.

                                                                                                Edit: Actually, given the proliferation of people who advocate for the literal murder and subjugation of their peers here, I’m just gonna delete my account. Y’all have fun.

                                                                                          1. 1

                                                                                            This sounds fantastic. I struggled for a while to build a Sway desktop on Ubuntu 18.04 in a vain quest to have my i3-like tiling in Wayland - this isn’t Wayland, but it does look like a great anti tide for configuration burnout hell.