goranmoomin

Last time I tried this, the fully-custom rendering with all of the custom UI, and the horrible text rendering forced me to not use the app. Honestly, using the app shows a lot on how much the Rust GUI scene is not a matured state. This is beyond the level of Electron, everything feels... just so unnatural (in a way that it makes Electron feel lovely).

Trying to understand the document as a Go outsider, but it seems that the document is assuming that the reader knows what Ps, Ms, and Gs are? Anyone knows what they are? It seems that it’s a scheduling resource… but I can’t find any further info.

Edit: It seems like

- P: Logical CPU cores

- M: OS-level threads

- G: Goroutines

> What exactly is missing/broken in jq right now which warrants a fork

AFAIK there’s quite a few bug fixes and features that are accumulated on the unreleased main branch, or opened as PRs but never merged.

IIRC I hit one of the bugs while trying to check whether an input document is valid JSON.

I should try checking out what’s happening to the fork, I’ve never opened a PR or something but I’ve read the source while trying to understand the jq language conceptually, and I’d say it’s quite elegant :)

Well, Foundation was a mature Obj-C library at that point, Swift’s future was unclear, and Swift needed to have better Obj-C interop anyway.

I think that Foundation being a Obj-C library effectively forced Apple into eating their own dog food (for the sorely needed Swift/Obj-C interop), so I don’t think rewriting Foundation in Swift would have been a good strategy for Apple.

After asking a few questions, I’m very disappointed with its quality compared to Bing Chat.

My current AI chat benchmark is to ask about LLVM APIs. I’ve asked to both Bing Chat and Bard three questions:

- What info can the LLVM lazy-value-info analysis pass analyze?

- Can you give me code samples to use the info?

- Can you give me a list on important LVI methods?

Both fared well on the first question, but on the second question, Bard either didn’t produce LLVM code at all (showing examples of LLVM IR), or hallucinate non-existent methods not even close to what existed.

Bing chat, in comparison produced correct answers that are very helpful. In my experience Bing chat almost always produces something that is both coherent and useful; Asking LLVM questions, Bing chat can search the Doxygen documentation, find out common LLVM patterns on its own (like using a Worklist while iterating), and I’ve succeeded in writing whole LLVM passes that compiled in one go, from a very light description of an algorithm.

Maybe I’m spoiled with Bing chat, but I don’t think I’ll be using Bard that much if it’s quality doesn’t improve. Very disappointed personally. (I’d have expected Bard to work much better mostly just because Google searches better than Bing.)

As a long-time Korean user of macOS, I hate the fact that APFS is normalization-insensitive yet normalization-preserving.

As a result, this means that… if you create a Korean-named file yourself in Finder: then the file name is normalized in Unicode NFD (decomposed) form, but if you create a Korean-named file in a zsh shell, the file name is normalized in Unicode NFC (composed) form.

You don’t realize the difference until you try an `ls | xxd`, but the bytes are different, even though they look the same.

It’s an invisible mess that people don’t realize until they do. And a lot of programs gets subtly crazy when fopen(A/B) succeeds but listdir(A) doesn’t list B.

This doesn’t use enterprise certificate; it creates a 7-day free developer certificate for each Apple ID, and uses it instead. That’s why there’s a server component in here.

> App data should fall into an predictable folder regardless of the location from where is ran

In fact, App Store apps are guaranteed to do that (by being in a closed sandbox); that's why Apple has an uninstallation procedure only for App Store apps.

> specify in a manifest what files and where will them be stored, and explicitly specify it they should be automatically deleted or not after moving the app to the trash

macOS tries to do that, and developers cry that macOS is becoming more and more closed. In fact, macOS already disallows all apps (including non-sandboxed apps) touching ~/Documents and ~/Downloads except for specific exceptions that the user grants.

Oh, didn’t expect a reference to me at all, was thinking that the function was very similar to mine :)

That function is now in my must-haves in my new Django side projects; I usually overuse them before I finally move to a JSX-based UI library. It’s great for simple DOM manipulation… and for me it seems to create a semi-simple migration path in the case the code gets complex.

It was common 5~10yrs ago to either have a spare Windows laptop or buy Parallels Desktop for handling bank/govt things. Nowadays, macOS got common enough that some of these ugly programs now have a macOS-specific version. :( Some even have downloadable deb/rpm Linux binary packages.

I’ve also wrote a comment on the context of how these ugly programs got adopted on [0].

To quote myself…

> Everybody knows that the systems are absurd. This is basically a countrywide legacy that we’re figuring our way out for ~30yrs.

> When the idea was first proposed, it was when IE didn’t have a yes/no dialog to ask whether to load native code or not.

> When IE first added ActiveX confirmation dialogs, banks instructed customers to press yes. When IE deprecated ActiveX, banks didn’t remove their 20-yr old code straight away; people were advised to turn on ActiveX support from advanced settings (they added step-by-step instructions to help people). When MS finally ripped out ActiveX, banks copied their ActiveX components into a separate executable that runs a localhost server.

I’m sure that if it wasn’t iPhones, South Korea would have been locked into this legacy for a lot longer. (In fact, we once had versions of these programs for Android as well! iOS didn’t allow this (thankfully).)

[0]: https://news.ycombinator.com/item?id=34313137

Honesty (from what I’ve heard) AFAIK the South Korean society itself is much more digitized than other first-world countries. It’s just that… digitalization happened a bit too fast with a bit too much legacy.

One can request a passport and receive it the next day from a machine without ever seeing a real person for more than 5 seconds… if you can tolerate installing these strange anti-keylogger programs.

A bit more context for people who don’t live in South Korea (I’m a South Korean):

Everybody knows that the systems are absurd. Most newer systems don’t require the use of such anti-keylogger programs. This is basically a countrywide legacy that we’re figuring our way out for ~30yrs.

This started in the 90s where South Korea got high speed internet everywhere, and people demanded internet banking… when IE didn’t ship 128-bit AES support due to export laws.

The South Korean govt submitted a law to enforce encryption for such services (i.e. an custom algorithm called SEED and 128-bit or higher keys were required), and without IE support, these encryption were developed in ActiveX. (For who don’t know, it was a COM-based solution to load native code from IE.) Laws and protocols are sticky, and even after IE shipped better encryption, these stayed.

When the anti-keylogger idea was first proposed, it was simple: the anti-keylogger could ship with the encryption support. It was when IE didn’t have a yes/no dialog to ask whether to load native code or not; everything felt easy, and at that point everybody got locked into this legacy mess where nobody could use different browsers other than IE.

When IE added confirmation dialogs, banks instructed customers to press yes. When IE deprecated ActiveX, banks didn’t remove their 20-yr old code straight away; people were advised to turn on ActiveX support from advanced settings (they added step-by-step instructions to help people), and when MS finally ripped out ActiveX, banks just copied their ActiveX components into a separate executable that runs a localhost server. (And that explains the hastily coded JSON support, the never-updated libraries, and so on that the article shows.)

Every time MS tried making running untrusted native code harder, the banks and customers got used to it… until it became acceptable to install 2~3 different executables for each bank, each running a server on a different port.

Thanks to smartphones, newer solutions now develop all of the encryption code in JS, and the legacy now runs in JS without native code. Still legacy, but it’s been much better for the last 5yrs.

Honesty this just seems that we’ve lost a lot of operating systems except for POSIX and NT. Imagine a libcurl for a SmallTalk machine… or a custom RTOS without any POSIX comapt layer; I’d bet Windows will seem easy compared to one.

In fact, maybe the fact that a Windows port of libcurl can exist at all means that the Windows BSD socket implementation is useful enough to allow these sort of things.

Quite interesting that a lot of comments mentioning the technical side of scaling, when the bulk of the post was about the more social side of things.

While I don’t agree that decentralization itself is a dubious goal, the argument that moderation, the legal side of things, etc… is not scalable (moderation especially in its current form where the entire fediverse can report anything) seems quite true? We can’t rely on generous people hosting instances, taking legal risks and spending time for it if the fediverse wants to grow bigger than what it currently is.

Or instead of all this, try MacPorts[0], which in my experience has 99% of what you need.

The biggest drawbacks are less support from quite niche packages (the ones that sets up its own homebrew tap), and a bit slower updates. But then I found it bearable much more than homebrew’s downsides.

[0]: https://macports.org

Only using the official API is quite cumbersome, as fetching a story with comments requires one network request per each comment.

Instead, try considering the (more unknown) Algolia API[0]. It supports fetching the entire tree in one request. Unfortunately the comments aren’t sorted, so you’ll still have to use the official one (or parse the HN HTML) if you need that.

For my HN client[1], I parse the HN HTML (as it’s required for voting), and sort the comments from the Algolia API. It’s much faster than recursively requesting the official API.

[0]: https://hn.algolia.com/api

[1]: https://github.com/goranmoomin/HackerNews

(While it seems that the project isn’t active) I’m interested not because of the Rust part but because of the more independent part, with plans to implement conditions and restarts [0].

I’ve mentioned a few days ago [1] about the lack of a clean and consistent lisp (in the development sense, not in the core-language-is-tiny sense) with a CL-like REPL-driven development workflow: maybe Clojure with conditions and restarts can be part of the picture?

(In Common Lisp, restarts and conditions are a major part of the REPL as it allows the REPL to have a mechanism to catch error conditions and allows the user to resume execution appropriately, after the user debugs and fixes errors.)

[0]: https://lisper.in/restarts

[1]: https://news.ycombinator.com/item?id=31179701

I’ve never did anything serious with Common Lisp, but my light experience on it was that

- the idea that almost all language constructs are user-implementable with macros is quite impressive (but I don’t buy the argument that “real” macros are only able in s-exprs)

- and the REPL-driven development model was a really beautiful and seamless experience.

But… every time I try to use it on some code, I find too many warts and inconsistencies that I just didn’t want to spend too much effort in making it work. It’s a beautiful language in it’s own ways, but the other parts are too ugly (to me, of course).

I’m fine with it being a lisp or not; I just want a clean language with macros baked in (and becomes the basis of most language features), and with a REPL-driven development model as a first class citizen (with interactive restarts and all).

Unfortunately it seems a pipe dream… so I’m stuck here.

[0]: https://mikelevins.github.io/posts/2020-12-18-repl-driven/

Honestly the macOS port looks very non-native to me — the black text in the selected tag gives me a very Qt/Swing feel… I’m very sure that Slint isn’t leveraging the platform native libraries. Very unfortunate.

Everyone is like how having Asahi makes Apple more profit, so it makes sense in a business sense, e.g... but am I the only person thinking that this is probably just one or two core kernel engineers just feeling good someday and decided to provide this to Asahi? I don't think the high-level people would really know that these changes even existed...

They’re VMs. It’s based on the Hypervisor.framework, so it’s actually faster than I thought, but it’s VMs.

Hello, I’m the developer. Didn’t expect a Show HN post to go into a second—chance pool — I woke up an hour ago to find that my app was trending on HN.

I developed this b.c. I found that I didn’t like HN mixed with other work/school related tabs, and realized that a separate app would be great for me. I believe that apps should use the most native-like UI possible — especially Cocoa on macOS, so I aimed to be the most ‘Mac-assed’ HN client possible.

Unfortunately the current app is in fact pretty unpolished — it’s in a usable state, but there’s a lot of missing features that one would expect from a ‘full-featured’ HN client. Probably a bunch of unknown bugs as well :-(. I would very appreciate any suggestions on feature additions or simple bug reports. Thanks!

You need a GUI. The user experience of GUIs are superior to CLIs in discoverability, consistency, etc...

The only reason CLIs are still useful is because we still haven’t found a way to compose GUI applications well. We still can’t automate GUI applications, use the result of one app from another app etc... But that’s not something inherent to the GUI paradigm.

Yeah, I'm interested too. I might be wrong, but AFAIK there aren't any specs on how a browser should implement forward/back buttons, right?

I'm personally getting a ton of mileage on the Safari's much more stable forward/back cache, the fact that you can go back reliably gives me more comfort than other browsers where going back usually refreshes the page (although I can't really explain how this is much better). I personally feel that this bug is more of a web app bug rather than the browser.

So if someone is interested in these Computer Graphics resources, you might also like these links:

Computer Graphics from Scratch: https://www.gabrielgambetta.com/computer-graphics-from-scrat...

The tiny{raytracer,renderer,kaboom} series: https://github.com/ssloy/tinyraytracer & https://github.com/ssloy/tinyrenderer & https://github.com/ssloy/tinykaboom

Ray tracing a tiny procedural planet: https://casual-effects.com/research/McGuire2019ProcGen/McGui... with the video on https://youtu.be/JvfjYuz7q4I

If you’re interested in this ‘Personal Data Warehouse’ concept, you might also be interested in @karlicoss’s articles[0][1][2] about his infrastructure on saving personal data.

There are various technical differences, for example @simonw preferring lightweight SQLite databases compared to @karlicoss preferring dumping the data and parsing-when-needed[3], but the purposes are similar enough that I think they should be mentioned.

There were also some very constructive HN discussion[4] on these articles, where @simonw have also introduced Dogsheep before :-)

[0]: Building data liberation infrastructure — https://beepb00p.xyz/exports.html

[1]: Human Programming Interface — https://beepb00p.xyz/hpi.html

[2]: The sad state of personal data and infrastructure — https://beepb00p.xyz/sad-infra.html

[3]: Against unnecessary databases — https://beepb00p.xyz/unnecessary-db.html

[4]: https://news.ycombinator.com/item?id=21844105

If you're a Mac user that cares about user experience, I would like to (aggressively) recommend Shrugs.app[0]. It's a Cocoa/AppKit app, made with macOS native technologies that integrates most of macOS features in the Slack experience. It's the best app in the town, surpassing Ripcord (which is developed in Qt and is ugly and foreign in macOS) or using Slack in the browser (my usual option), or using the Electron client. It's written by Helge Heß[1], which you might have heard about - he has some fun projects like SwiftWebUI[2].

[0] https://shrugs.app

[1] https://www.helgehess.eu

[2] https://github.com/SwiftWebUI/SwiftWebUI

Hmm, not really related to the story (or HN comment), but I thought HN comments became automatically dead when submitted... [0] I guess someone decided to vouch for this?

Is my guess right? Can someone shed some light on how this is not dead?

[0] https://news.ycombinator.com/from?site=ycombinator.com (view it with showdead on)

While I do like the new wave of the structured shells(elvish, uxy, nushell, crush, etc...), I don't think anything will actually succeed unless there's a big change in the operating system.

(I'm not suggesting these aren't valuable - these are valuable experiments, but I'm saying for them to succeed, a new OS is needed.)

The native OS doesn't really embrace structured communication, and so commands will still have to treat the structured shell as a second-level citizen.

In an ideal world, for the structured shell to work, 'npm list' should return a table (or whatever the native data structure is) and you should be able to do 'npm list | where {deduped==false}'. In the real world, 'npm list' won't support the structured shell, so you would be writing 'npm list --json | jq '<obscure commands>' | json:from | where {deduped==false}'. And then 'npm list | grep -v 'deduped' is more simpler, so you don't really feel the advantages of the structured shell.

I think for this to be solved, the OS's primary communication system should be structured, so you can guarantee that every command will be a table. Then the programmers for the tools of that OS will output a table, and the users will be able to take advantage of this. Until then... it's basically a fun experiment.