watusername

mosh is neat, but I've mostly switched back to good'ol SSH over Tailscale due to various rendering bugs caused by client-server mismatches as well as the lack of port forwarding.

Basically mosh attempts to synchronize the state of the terminal which is made up of character cells. It sounds simple until you realize that unicode and fancy escape sequences exist, and the behavior of the client and the server must match otherwise you get weird misalignments that are difficult to debug:

- Unicode 9+ changed character width computation a lot, but macOS `wcwidth` still follows the old algorithm. Let's patch it: https://github.com/mobile-shell/mosh/pull/1289

- There is no support for strike-through and dimmed styles. Let's patch it: https://github.com/mobile-shell/mosh/pull/1059

- What about underline/undercurl? Let's patch it: https://github.com/jdrouhard/mosh/commit/aff5e1c3db9f061deb2...

- Some emojis don't take up two cells as expected? Again, let's patch it: https://github.com/jdrouhard/mosh/commit/b31161ab311c7b6e306...

- ...

You really need those patches to have a good experience, and popular mosh clients like Blink on iOS incorporate them in their builds. However, things look wonky if you don't use the corresponding server builds, and you don't want to dig through layers of abstractions to find out why selecting lines in a specific file in neovim causes everything to become a jumbled mess every so often.

There is no end in sight for those patched to be merged upstream, no end in sight for distros to ship new versions, and no end in sight for protocol changes to make state synchronization more resilient. So, back to SSH we go...

Edit: Fixed wrong link for underline/undercurl patch

To be frank, the whole post reads like "I hate change" with no convincing argument otherwise. The author even acknowledges the very lenient ramp-up from CAB _and_ the myriad of available tooling, yet still throws his hands up.

> I am responsible for approving SSL certificates for my company. [...] I review and approve each cert. What started out as a quarterly or semi-monthly task has become a monthly-to-weekly task depending on when our certs are expiring.

I don't get the security need for manually approving renewals, and the author makes no attempt to justify this either. It may make sense for some manual process to be in place for initial issuances, as certificates are permanently added to a publicly-available ledger. And to take a step back, do you need public certs to begin with? Can you not have an internal CA? Again, the author makes no attempt to justify this, or demonstrate understanding in the post.

> email-based validation may as well not exist when we need to update a certificate for test.lab.corp.example.com because there is no webmaster@test.lab.corp.example.com.

I know that this is an example, but as a developer it would be a pain to have to go through a manual, multi-day process for my `test.lab.corp.example.com` to work. And the rest of the post seems to imply that this is actually the case at OP's org.

> Which resource-starved team will manage the client and the infrastructure it needs? It will need time to undergo code review and/or supplier review if it’s sold by a company. There will be a requirement for secrets management. There will be a need for monitoring and alerting. It’s not as painless as the certificate approval workflow I have now.

There are additional costs and new processes to be made, yes, but even from a non-technical POV this appears to be a good time to lead and take ownership.

> Any platforms that offer or include certificate management bundled with the actual services we pay for will win our business by default. [...] What is obvious to me is that my stakeholders and I are hurrying to offload certificate management to our vendors and platforms and not to our CA.

That's okay. If you hate change and don't want to take ownership, pay someone else to take ownership.

From git's perspective, jj bookmarks are just regular git branches, so you can just do `jj git push` and open a PR as usual.

However, unlike git, jj bookmarks are pinned to change IDs instead of immutable commit SHA-1s. This means that stacked PRs just work: Change something in the pr-1 bookmark, and all dependent bookmarks (pr-2, pr-3, ...) are automatically updated. A `jj git push --tracked` later and everything is pushed.

Only the invoked app knows whether it needs the focus in the first place. Maybe the link you clicked is supposed to initiate some background processing that does not demand your focus at all.

One issue that comes with leaving GitHub is a higher barrier to contributing. The author appears to see this as a nice filter, but it may not make sense for you. With a self-hosted forge, a new contributor will need to:

a) Sign up for an account in your forge: Do contributors really want another account? Does your captcha/email verification actually work (I've encountered ones that don't)? There are also forges that require you to ask for an account which is another hurdle.

b) Send an email: Configuring `git send-email` is alien to many contributors and may not even be doable in some corporate environments (OAuth2 with no app passwords allowed). Diverging from this is error-prone and against social norms which the contributor may not even be aware of (until they get flamed in the mailing list). You are also giving up automated CI which is a big part of the contributor feedback loop.

To be clear, going independent does indeed work for small personal projects (do not care much about contributions) as well as established ones (large incentive for new contributors to jump over hoops), and I'm fully aware that a lot of HNers do not see the need for those "niceties" provided by GitHub. But I feel that people often underestimate the barriers that they are putting up.

Judging from the comments here, it should be called "the book of nft" for comedic effect :)

You go to https://code.visualstudio.com and it will appear that AI integration is the whole point too. How a thing is currently marketed != How people have been using it.

Other commenters have already provided examples for other languages, and it's the same for Rust: async functions are just regular functions that return an impl Future type. As a sync function, you can call a bunch of async functions and return the futures to your caller to handle, or you can block your current thread with the block_on function typically available through a handle (similar to the Io object here) provided by your favorite async runtime [0].

In other words, you don't need such an Io object upfront: You need it when you want to actually drive its execution and get the result. From this perspective, the Zig approach is actually less flexible than Rust.

[0]: https://docs.rs/tokio/latest/tokio/runtime/struct.Handle.htm...

The point is that people want to fund the development of the actual browser engine which is more important than the customization scripts that those forks maintain. The engine is what people are worried about.

Fortunately (or unfortunately depending on your perspective), Play Integrity is bit of a joke at the moment thanks to a group of OEMs who just can't seem to secure their private keys. Unrevoked keyboxes are publicly available.

You are not the target audience. This is aimed at casual users and beginners, and it's already in a good shape to replace nano with its user-friendly, mouse-enabled TUI.

It already works? There just isn't an official build yet - just `cargo run` yourself.

Well, read the next paragraph. It's clearly an acknowledgment of privilege and an appeal:

  “I know I will get due process and that my rights will be protected,” Lander said to a throng of supporters who gathered spontaneously in Foley Square that evening after his release.
  
  “But Edgardo will sleep in an ICE detention facility God knows where tonight…he has been stripped of his due process rights in a country that is supposed to be founded on equal justice under law,” Lander continued, naming the immigrant detained by federal agents at the same time the comptroller was taken into custody.

Just to expand a bit on the sibling comment, IPAs downloaded from the App Store are encrypted with a DRM scheme with a key tied to the Apple account. The binaries actually stay encrypted on-disk and the OS has facilities to transparently decrypt them when executed. The usual way of decrypting is to actually execute the app, attach a debugger (normally not possible for production apps) and read the decrypted code from memory.

It used to be kind of distributed, but Google has been strong arming carriers to use their hosted Jibe service through a combination of proprietary extensions (e.g., E2E which is finally standard) and bypassing carrier control (if the carrier didn't provision RCS, Google Messages would use their own service iMessage-style).

From the end user's perspective, if the carrier didn't use Jibe RCS, it simply wouldn't work well.

> editing is needlessly annoying.

Luckily, this does not matter in DiffX because the whole thing goes up in flames when you change the length anyways :)

> In the bubble I live on, classical VMs have become the exception nowadays, containers and serverless deployments are the rule now.

Nix does not require NixOS, and I would even wager that in corporate dev environments it's most often used in a standalone manner.

You can install Nix on Debian/Ubuntu/RedHat, get a reproducible local dev environment and build reproducible OCI images that can be deployed to K8S/Cloud Run/Fargate/etc [0], without ever touching NixOS.

[0]: https://nix.dev/tutorials/nixos/building-and-running-docker-...

> some customer imposes it on our delivery contract

It's happening: Companies are adopting Nix [0] and you may see such requirement come up some time.

[0]: https://github.com/ad-si/nix-companies

Terminal business cards are a nice idea, but RCE business cards are just asking for trouble. Instead of npx, what happened to good'ol curl? Something like

$ curl ashley.dev

Some decades ago, we had finger (https://en.wikipedia.org/wiki/Finger_%28protocol%29) which is designed for this very use case. Sadly it's no longer installed by default with most distros:

$ finger @ashley.dev

First of all, thank you for trying to resolve this with the carrier and finally bringing it up to everyone's attention here. Perhaps public attention is what's needed to push them to address the problem.

To be honest, I personally would be scared to report such vulnerabilities with my real identity to begin with. With big tech companies, no matter how poorly their bug bounty programs are run, I still have this naive expectation that they won't shoot the messenger. At worst they could ban my accounts and maybe send threatening letters, but they probably won't ruin my life as long as I abide by the norms (agreed by technical people).

However, I do not feel the same naive optimism towards "legacy" institutions like telecoms and public services. At best it's thankless work, at worst I get sued [0] or become a scapegoat so some official could score some political points [1]. It's unfortunate - I am acutely aware that this is chilling effect at work, and our systems are collectively less secure because of it.

[0]: https://www.cnbc.com/2024/09/15/dark-web-expert-warned-us-ho... [1]: https://techcrunch.com/2021/10/15/f12-isnt-hacking-missouri-...

> Dumping data from the memory of your phone can't be unauthorized.

> just dumping the diagnostics for regular phone calls should be fine

IANAL, but computer hacking laws like the CMA in the UK and CFAA in the US are written in a manner so vague that even pressing F12 to view the source of a web page could be a violation [0]. From O2's perspective, they could argue that the OP has accessed their internal diagnostic data in an unauthorized manner. What we (technical people) think is irrelevant.

[0]: In the US, the DOJ has revised its policy to not prosecute defendants pursuing "good faith security research," which you may trust at your own risk: https://www.justice.gov/archives/opa/pr/department-justice-a...

As one example, they (core contributors and founder) were, and still are, very heavy-handed regarding how you are allowed to install their software: https://news.ycombinator.com/item?id=27505277

Well, in an ideal world, _everyone_ would be using informative headlines, regardless of whether they are shutting things down or not.

For this post in particular, "An Early Look at Fresh 2" would make a better title, albeit with less "clickbait potential" (well, people love drama). With a "An Update on X" headline you both fail to inform and give the impression that you are killing the thing.

Please do not title your posts "An Update On X" if you aren't shutting it down. You can blame the SV startups for the connotation but that's where we're at now. But in this case, I guess it has worked as a form of clickbait :)

Looking at the whole interaction as well as the AI patch (https://github.com/llvm/llvm-project/pull/125602#issuecommen...) the author submitted, I have to disagree. It removes the flag setting altogether and adds useless code. It demonstrates that the author really has no understanding of the code, which may be okay for your weekend SaaS but definitely not for build system code in critical compiler infrastructures. To put it bluntly: This _is_ AI slop.

There's no denying that AI is helpful, _when_ the human has some baseline knowledge to check the output and steer the model in the correct direction. In this case, it's just wasting the maintainers' time.

I've seen many instances of this happening in the support channels for Nix/NixOS, which has been around long enough for the models to give plausible responses, yet too niche for them to emit usable output without sufficient prompting:

"No, this won't work because [...]" "What about [another AI response that is incorrect]?" (multiple back-and-forths, everyone is tired)

> cracked WhatsApp binaries

On a more meta note, I wonder who even works at companies founded on ideas that are just... bad. On average, I expect good engineers to push back on such business requirements and also have better job mobility so they can leave and work elsewhere. The researcher found the vulnerabilities "in less than 30 minutes" so it seems there's some lack of competence here.

Unfortunately, misguided business requirements like this won't simply disappear and I get that those can be niche offerings that attract juicy contracts.

LuaTeX is the de facto successor of pdfTeX and is basically a more maintained pdfTeX with Unicode support and Lua scripting, whereas XeTeX has its own engine. In practice, it means that LuaTeX "just works" with most documents while with XeTeX you run into all sorts of weird incompatibilities. Fancy packages that make use of Lua scripting (e.g., graphdrawing) will only work with LuaTeX.

Edit: Looks like it's not de facto anymore, and LuaTeX is now recommended for all documents and XeTeX is being recommended _against_ (https://www.texdev.net/2024/11/05/engine-news-from-the-latex...)

Check out Tectonic which is an all-in-one LaTeX toolchain (single executable w/ engine + build system) that lazily downloads TeX Live (no upfront multi-gig downloads). It's a breath of fresh air in the chaotic LaTeX landscape. Bit of a shame that they opted for XeTeX rather than LuaTeX though.

[0]: https://github.com/tectonic-typesetting/tectonic

According to the new 404 Media article [0] about the app's archive server actually being hacked, TeleMessage does have contracts with several governmental agencies. Still not a direct answer to the question, I know, but it tilts the answer overwhelmingly towards "yes."

[0]: https://www.404media.co/the-signal-clone-the-trump-admin-use...

I concur. An analysis of potential risks and vulnerabilities is a different beast from actual proof that the app has indeed been hacked. I call for the other discussion to be restored.

Edit: Wanted to respond to the top-level comment but you get the point.