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).
462 karma · joined January 22, 2015
Now I install far more packages via devbox (or devbox global) than I do via HomeBrew (on osx) or pacman (on arch).
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.
What is the US going to do, apply more tariffs?
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.
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.
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.
> 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.
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.
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.
Isn't the amount of profit the company is making (and how that will change) what matters and not what its share price is?
Having a separate device for separate tasks, can often be quite useful.
Why is increasing your code coverage to 100% matter? Would that reduce bugs or speed up development in any way?
Wouldn't it just add lots more code to maintain and make refactors more time consuming?
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".
In that context, counting where the number of attempts is 0 doesn't add anything to the thesis.
An article from Yahoo [0] says it's "$29.99 per month or $167.99 per year", but they don't link to a source.
[0] - https://au.finance.yahoo.com/news/duolingo-launches-subscrip...
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.
A better description would be "A PHP based web app which calls OpenAI's Whisper API to transcribe speech"
The first result in Google [1] which I often use, lets me paste a unix timestamp in seconds, milliseconds or nano seconds, and it accordingly converts it to a Human readable string.
Is that not the feature you built this for?
[0] - I understand that types can be added on top, but I never found the integration to work that well with mypy when I last tried it many years ago.
I understand not being fond of the its ubiquity, especially with many Websites now requiring Chrome. And Google is allegedly abusing their dominant position. But banning it? Why?
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.
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/
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:...
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.