HN user

vhanda

462 karma
Posts4
Comments131
View on HN

Nix has a high learning curve. I now use Devbox [0] as it hides all the complexity of Nix while still giving all the benefits.

Now I install far more packages via devbox (or devbox global) than I do via HomeBrew (on osx) or pacman (on arch).

[0] https://www.jetify.com/devbox

The bigger problem for me is buying Ebooks without DRM, which are cheaper than the paperback. I see no reason why I should be paying the same (or often more) than the paperback version.

Just let me buy the ebook and let me own it.

Right now, after pirating it, I have to find the author's patreon / something and contribute some money that way. It shouldn't be this hard to give someone money.

Keep Android Open 5 months ago

They way we usually do, by restricting their access to EU markets unless they comply and/or fine them, and/or threats about nationalizing the "EU Google".

What is the US going to do, apply more tariffs?

Could you please elaborate on how this is different than the other python based modeling tools - build123d[0] and CadQuery[1].

I recently also got annoyed with OpenSCAD and its limitations and therefore started experimenting with Build123d. I'm very much a beginner in the CAD space and would love to understand what inspired you to build sdf.

My basic understanding is that STL files are essentially like Bitmap images and store a list of triangles and their positions, whereas STEP files are more like Vector art where there is a list of instructions on how to build the model. Most CAD GUI programs also operate on a similar model to vector art where they record a list of operations one on top of another. It's why STEP files are a standardized format and can be imported / exported from most GUI based CAD builders. I think.

Given that SDF also seems like it builds only STL files (I could be wrong), wouldn't learning build123d or CadQuery work better if one cares about compatibility with existing GUI based CAD modeling software?

Additionally, atleast build123d offers a similar conceptual model to using Fusion360 and FreeCad - I have limited experience here - but essentially you sketch something in 2D on a particular plane, and then apply some operations to convert it to 3d in a particular manner - the simplest being extruding. This means the mental modeling of how to construct something is very similar across both GUI based CAD programs and Build123d, and that makes it easier for me to jump between GUI based and code based CAD modelling.

I'd love to understand your point of view, and learn more.

[0] https://github.com/gumyr/build123d

[1] https://github.com/CadQuery/cadquery

I was thinking along the lines of how much I actually watch, if I only watched 10 minutes of your show, I only pay for 10 minutes, not the entire thing.

You're also saving on bandwidth.

Paradoxically, I'd still want to pay per minute of viewing time, if I'm watching the show on 2x the speed.

All streaming services should have a pay per minute system as an alternative to the fixed monthly subscription.

That way, I'd happily use any service to watch whatever cause it would be convenient, instead of piracy.

And it would be a reason for them to really improve their recommendation systems.

From the article -

this paper was not a retrospective study of electronic health records, it was a randomized clinical trial, which is the gold standard. This means that we’ll be forced to immediately throw away our list of other obvious complaints against this paper. Yes, healthier patients may come in the morning more often, but randomization fixes that. Yes, patients with better support systems may come in the morning more often, but randomization fixes that. Yes, maybe morning nurses are fresher and more alert, but, again, randomization fixes that.

Not who you're asking.

I really don't see why we're still using A/C inside our houses / apartments. I understand that the transmission loss is lower when sending A/C, so it makes sense, but then nearly every device in my house has their own AC to DC converter. Just have one AC-DC converter per building.

I'd like the future to just be USB-C sockets in my house. We have USB-C PD 3.1 which supports up to 48v, I imagine that would be good for all devices.

There are probably safety reasons why this future might be difficult.

I think what they meant is that if it's hosted online / home-network, only allow access to all services through a VPN. Wireguard is relatively easy to setup, and you can configure all your services to only be available through wireguard.

Ever since ssh almost got backdoor-ed, the only thing "exposed" on my servers is Wireguard, which is UDP based and therefore harder to know if it's running. SSH also goes over wireguard.

Wouldn't the share holders care more about the profits of the company which are then being given as dividends instead of the price they can trade the share price at?

Isn't the amount of profit the company is making (and how that will change) what matters and not what its share price is?

then their billion dollar app distribution monopoly money hose will be in jeopardy

It only comes under jeopardy, if there are reasonable alternatives the Apple app store (not move to Android).

Otherwise, it's easy for Apple to say - we are now taking step x, y and z, and "trust us".

The aggregate is the number of attempts at "Entrepreneurship" across class boundaries. The thesis is that Middle class kids get far fewer attempts vs richer kids.

In that context, counting where the number of attempts is 0 doesn't add anything to the thesis.

Duolingo seems like they have separate teams for iOS, Android and Web.

Their iOS team seems to be the one who experiment the most with new features, and then they either get discarded or finally make it to Android, and then in a few years to the Web.

It is really annoying, as when I used Duolingo (stopped because of the new update in Jan), I would often use all three platforms, and have the worst experience.

I found the JavaScript nodes to be quite annoying. Specifically -

1. I want a proper IDE

2. Proper typing so the feedback cycle is faster.

3. Being able to use external packages

4. Being able to quickly test my custom node across old runs.

Their JavaScript nodes take me an absurd amount of time to get right. And I've needed to use them far more often than I would like.

This is fascinating. It checks a lot of my boxes. I was recently looking at ActionsFlow [0] which is similar but runs on GitHub Actions.

My thoughts -

1. I don't see proper secret storage being handled. You typically don't want your API keys in your code. What would you recommend instead?

2. "OAuth" based secrets. Many integrations require giving access to an App via OAuth, which involves a flow. I think that's being handled internally from the video [1] and from this project [2], but it's not clear. How is that handled?

A common use case I'd automated once is that when a GitHub project gets starred, the developers public information is scrapped and they are then followed on Twitter, if their twitter handle is found. With Trigger.dev, the twitter part isn't clear.

3. Error Handling - What about when some job fails to run? I understand there is a delay mechanism. But what about injecting custom error handling? Sending a message on slack, for example.

4. Dashboards - They look awesome. And I get the impression that each "action" in the code is mapped to individual blocks in the dashboard. I'd love to be able to see a proper graph of the flow.

I love that I can see the json request / response for each. It'll make debugging easier when some API changes or fails.

5. No Code solutions - In the long run, I can easily picture writing the integration I want in plain text, and having Github CoPilot or ChatGPT generate the code for me, and then I can quickly modify it.

6. Incentive for integrations - As with most automation tools, entering the market is challenging as you're lacking integrations. The awesome thing about ActionsFlow [0] was that it was re-using an existing community of GitHub Actions, and therefore you don't start from scratch. Have you thought about reusing workflows from n8n or other projects?

7. Integrating with existing Automations - I think a bit more focus should be made on integrating with IFTTT / Zapier / n8n. I see you provide webhooks, but I think some easy wrappers + documentation would be better. This way, I can try out newer workflows in Trigger, and easily just extend my existing system. And then if Trigger.dev works for me, I can think about migrating away from my existing automation solution.

8. Open Source Longevity - Trigger.dev is MIT licensed. Could you please explain the rationale? How do you plan to combat someone launching a competitor using your code? N8n is deliberately "Soure Code Available" and not "Open source", which I thought was a decent compromise. Will you be following a more Open Core model similar to GitLab (which is also MIT licensed)?

9. De-coupling runners and the dashboard - I'd love to not have the pain of maintaining the dashboard / event listeners, but being able to control the running of the jobs. Similar to a CI or Airflow.

10. Support for other languages - This is something that Dagger CI [3] now allows. Letting you use whatever programming language. With Github Actions, I can just package it as a container. Do you plan to support anything else?

After moving from using HCL to Typescript for my Terraform code, the advantage is so great, that I can't seem myself going back to using a custom language such as Dagger's CUE [4]. Trigger.dev targeting Typescript is already a big win. However, I do have a number of automations in Python.

Overall, I'm super optimistic. Congratulations on the launch.

[0] https://actionsflow.github.io/

[1] https://www.youtube.com/watch?v=aFlwD0frvnQ

[2] https://github.com/triggerdotdev/Pizzly

[3] https://dagger.io/

[4] https://docs.dagger.io/1215/what-is-cue/

I wonder how did they get into poverty in the first place. A lot of areas that are now declared as poverty zones today may have been poor in the past, but were self-sufficient and self sustaining.

Well, when the British left in 1945, roughly 15% of the country was literate [0], now that is up to 77% [0]. From here [1], it seems that poverty was around 45% of the population (361 million). It also says the rate varied based on how the monsoon season went, which makes sense for a primarily agrarian society, especially one which had to import food to meet their needs till 1965 (roughly).

so, basically, the British didn't leave India in a good place. See [2]

[0] https://en.wikipedia.org/wiki/Literacy_in_India#/media/File:...

[1] https://pdf.usaid.gov/pdf_docs/PNACR801.pdf

[2] https://en.wikipedia.org/wiki/Bengal_famine_of_1943

In my experience, it's normal.

Eventually you get used to it, and start ignoring it. Sadly. I'd switched to Gnome for many years, but in the end - being able to easy tweak the desktop to my liking drove me back to KDE.