frompdx

This is for you, @Pickletickler9000, and everyone else who has bought a pre-built PC. You can build your own PC. It is very easy and you can build them in all kinds of shapes and sizes. It is also much less expensive. The sky is the limit for $2700. Take the money and build something to your specs so you can go back to your video editing gig.

All of these blow what you had out of the water.

https://www.reddit.com/r/buildmeapc/comments/1b599jy/the_abs...

Learning to create a web app is a fine endeavor, however, if you already have something that works and you want to sell it to other students why not focus on that? For example, what if you sold it on itch.io to other students? That way you have a sense for whether or not people are willing to buy it before you decide to rewrite your app into a web app.

I agree. NATS is much more simplistic to use and deploy. Easy to run locally for development. Jetstream offers useful features like persistent streams, and kv and object stores.

  During the work day I need to provide results not just learn

Results come from learning.

A lot of people are focusing on why insurance is complicated in the United States, but I'll do my best to answer why tech has not made this more simple.

  Why tech hasn't simplified health insurance?

There are no incentives for an insurance company to make the process easier. Their incentives are complying with the law while minimizing payouts. Insurance companies make large technology investments in making this happen. Providers are also incentivized by complying with the law, but instead of minimizing payouts they maximize their billing to the insurance company. They too make large technology investments in making this happen. No one is incentivized to make any of this easier for the patient, so why would they pay for tech to solve that?

Beyond that, yes there are regulations that make things complicated. Chiefly HIPAA, but also the ACA. The real challenge is a solution that makes everything more simple for the patient while appealing to providers and insurance companies that have conflicting incentives. Is there a tech solution for this?

  But this gets them in trouble with insurance providers for some reason.

What kind of trouble is this getting Zoomcare in? I've never used Zoomcare, just curious.

  can be a solution of traveling Sales Problem(TSP)

Can be, or is?

I've been picking up Elixir and the Pheonix framework and I'm impressed so far. Pheonix is a very productive framework. Under the hood Elixir is very lisp-like, but the syntax is more palatable for developers who are put off by the syntax of Lisp.

Why isn't it more popular? It's always an uphill battle to introduce a new programming language or framework if BIGNAME doesn't use it.

I disagree that GDScript is a poor builtin language. It is somewhere between Python and JavaScript. It gets the job done and there is a lot you can do with it. Signals are great for things like state management. I'm not really sure what you mean by spaghetti code and how signals are supposed to help. I do agree that there are some annoying OOP aspects like providing a path to a scene (module). It's verbose but not unlike library imports in other languages.

This post has generated a surprising amount of conversation for how little documentation this repo has. Looking at the code this looks more like a project rather than a game engine. The property editor looks interesting. Seems like this post is being upvoted based on the title vs the content.

Make your own Geo-site or your own GeoCities. https://code.divshot.com/geo-bootstrap/

Others have mentioned Godot and I really recommend it as an introduction to game development. It is very easy to pick up and the default programming language (GDScript) is easy to learn. I have a few small games and plenty of PoCs with Godot.

While many engines can be ported to the switch, including Godot, your son won't be able to do that with the Switch he has. This requires an official dev kit, which requires approval from Nintendo. See this thread to get an idea of what is involved. https://old.reddit.com/r/godot/comments/1f9o4sp/i_just_recei...

If you think your son will be motivated to make a game for a handheld platform I recommend the Steam Deck. Your son can install Godot on the deck and with a mouse and keyboard attached your can actually use the Deck to both build and play his game. The short feedback cycle will hopefully keep him engaged.

Get a high quality office chair from Steelcase or Herman Miller. A used Herman Miller Mira Aeron is better than any new office chair for of the same price. Replace the gas cylinder if it's worn. It's relative easy to do at home.

Sit/sand desk. Even if you don't use it in standing mode the ability to adjust the height easily is worth the price.

If you use a Macbook, get a monitor with complementary resolution.

Good lighting with dimmers.

Why do you disagree 1password is good enough for business?

Believe it or not, it's an 1984 K10 Scottsdale with the 6.2L Detroit Diesel. It was also my first car. Small world.

My truck. It has sentimental value as my first car. I just gone done with the water pump and I just solved my steering "pop" issue. Next up is a new steering wheel as the old one is gross and sticky. While I'm at it I'm going to install a new turn signal/wiper control lever and fix the turn signal auto-off spring.

I think the price is right for a small business that is trying to catch someone's eye. Very unique and more subtle than a LCD display. I could see it in a coffee shop or a tap-room.

I would love a smaller version for my home office. Not sure what I would use it for. Maybe some app monitoring info.

  What do we really need LLMs for that humans can't?

I would argue that it's not about whether or not we need something that humans can already do, it's that we don't want a human to do those things because a machine might be able to do it better, faster, cheaper, etc.

A human can operate a lathe, I used to do it, but the CNC lathe I also operated could do any thing I could do much, much faster with just as much accuracy.

The scaffolder is the part Datadog won't get you, and in my experience it is the most useful feature.

Helm is what you should use as your cluster "package manager" to install all of your favorite off the shelf tools. Kustomize is probably a better choice for shipping your internal projects due to the variations you mentioned, but also because the learning curve isn't much steeper than learning about how to work with plain Kubernetes manifests.

Backstage is an open source CNCF project. It needs a corporate sponsor to keep it alive.

This is in reference to the software catalogue feature.

The trouble with the way Backstage is designed is that it makes keeping everything up to date difficult. It is also harder for them to ship updates for their core and plugins due to the labor involved in incorporating any updates.

A plugin architecture like Wordpress or Grafana is much more manageable for an operator. In fact, a set of plugins for Wordpress could probably get you an equivalent solution, but it's PHP, so you know, ew. I'd love to see an alternative to backstage that gets it right.

My company uses it. Our team is about the same size. I have mixed feelings. It has been useful for things like making sure a new repository is created with all of the CI goodies every project should have. You can also use it to automate things like opening PRs against your gitops repo to get apps deployed from a template.

Creating software templates can be a large investment. It would be great if there was a software template marketplace. The backstage contributors took a stab at this by creating a template repo that has not been updated in about a year. https://github.com/backstage/software-templates

If you do invest in creating a template, be sure to get plenty of stakeholder feedback so the thing you make is something that actually gets used.

  Backstage is built on a modular, plug-in based architecture that allows engineers to layer-up their developer portal to meet their own needs.

Frankly, this is just incorrect. Just read the configuration guide for "installing" a plugin to see what I mean. You have to modify the source code of your own deployment in several places. That's not a plugin based architecture.

https://backstage.io/docs/getting-started/configure-app-with...

Additionally, check out what it takes to stand up a standalone backstage server. You used to have to clone their repo if I remember right, but now they give you a starter template via npx and leave it up to you to put all of the pieces together. They don't even ship a docker image to get you started.

https://backstage.io/docs/getting-started/

Frankly, the architecture of Backstage is ill-conceived and a hassle to operate. If you have the budget their are vendors that will deal with all of this for you. I think the concept of Backstage is fine, but the execution leaves a lot to be desired.

Thanks for the reply. That's roughly the strategy I'm thinking. In the past I would have also reduced the domain TTLs well in advance. You are probably correct about those using unreasonable TTLs on their nameservers.

> Also they do not let you edit the TTL of records

That's going to make migrating name-servers painful. What a nightmare.

Edit: Just confirmed on my domains that moved. You cannot update the TTL of any record.

Can anyone suggest a strategy for safely migrating DNS providers without changing the current TTL settings since they can't be updated?

This release is interesting because of the theme. I don't remember much controversy about the many Star Trek themed releases. However, in the past being a trekkie was uncool and being called a trekkie was practically a slur. I think that is worth keeping in mind when discussing the theme of this release.

On the flip side, as a practitioner I care more about the tech than the themes. People can get hung up on the smallest things. I don't want the release theme to get in the way of the tech as much as it pains me to suggest stripping away the light natured individualism of the release theme.

> Oh yeah, CAD for maintenance manuals. The engineering design system, that's a great place for parts lists.

This was always a fun one. We realized right away that the data in the CAD models was superior to the technical drawings we received as PDFs (most of which, awful scans of paper documents). However, only the technical drawings were acceptable for the type-certificate. Our manuals were part of the type cert, so we had to verify everything agains the crappy PDFs anyway.

From my experience technical documentation for aviation was made challenging by the corpus of engineering plans that were signed, initialed, and scanned into a PDF as an image. Modern machine learning to ingest that data and produce a diff would be very useful even if it still needed human review.