Hacker Newsnew | past | comments | ask | show | jobs | submit | more Catbert59's commentslogin

> Any files or data you upload Any generated code or data”

That renders it entirely unusable for us :-(

We work a lot with heavily NDA'ed datasheets/sources.


ESP32 works okish with Gemini/GPT5 and Claude.

They offer a lot of public example code and documentation. LLMs inhaled that.

But they still produce a metric ton of unusable hallucinations.


I've been trying to start on embedded in my own time, but I don't have much experience at all and have been spinning my wheels getting up to speed. I'm generally YouTube/docs first, but do you find any particular LLM to be most helpful and reliable at a introductory level?


No really.

If you want to learn embedded you should try to understand the example codes the vendor supplies.


Problem is that most our embedded stuff is heavily NDA'ed and will never (and isn't allowed to) end up in LLMs. So we will be sticking to hand-writing most stuff.

At work we have access to the latest LLMs (Claude, Gemini, Open AI) and they are not really usable. The code looks great (which makes it extremely hard to debug) - but produce too much hallucinations.


Like all military stuff: 60 years old chassis to avoid recertification but stuffed with latest tech.


That's weird.

The company I'm working for has its own EMC chamber (maintaining that huge room fully calibrated and standardized is ultra expensive... just looking at these EMC test receivers that go up to 40GHz my me cry in $$$$) and we invested giant engineering effort into our products to be far below every radiation limit norm in the world.

Shouldn't satellite companies have even better stuff and more strict regulations or are these unintended effects maybe caused by the harsh environment?


They did. These are sub 1 Ghz bands and the issue is from the engines and (maybe power supply)


Most communications satellites (which is all Starlink really is) are heavily focused on their operating bands and any specific bands they are told not to interfere with so they can get launch approval. There's no benefit to doing anything extra. And not only do they have to be told which specific bands they can't interfere with, the government actually has to require delivery of test results or else that is the same as giving permission to interfere.

Most companies won't spend a penny, take a second of time, or add a gram to a satellite if it doesn't affect their mission or chance of approval. Especially not one as cost-optimized as SpaceX. They won't change a thing unless the US government forces them to do so, or if they think that a government order is imminent so they come to some voluntary agreement ahead of time to avoid what would probably be a more constraining official regulation in the future.

The actual issue is probably caused by switch-mode power supplies or some digital signal on the satellite that isn't fully shielded, possibly one that does digital control of a motor or thruster. It probably isn't the communication radios since they operate at a much higher frequency. You can fix the issue by adding filtering and/or shielding, but that takes extra components (meaning extra cost and weight) and requires testing (meaning time). Plus you have to identify the offending system, which means you have to start with testing and detective work. This interference was only detected on some Starlink satellites, so you have to do detective work to find out if it is a particular operating mode or generation of satellite that is offending, do testing to confirm it, and then work on a fix.


This is actually not correct for Starlink. They did a lot of work to lower their albedo based on astronomer complaints, even though there wasn't any government regulation in this area.

It might apply to some of the emerging Starlink competitors however, especially the Chinese ones and AST.


The albedo reduction they worked on is the exact reason why I wrote this, "...or if they think that a government order is imminent so they come to some voluntary agreement ahead of time."

SpaceX only "voluntarily" did that because the government was likely to put more stringent requirements on them if they ignored the complaints.


I’m certain that SpaceX does not care about regulations


Private stuff: gitea on a cheap VPS. Will most likly migrate for Forgejo in the future. That stuff runs on a toaster.

Public projects: Github. Having no problem with it. Also makes me happy poisoning LLMs with my shitty code.


I run Gitea on my old Synology NAS, fast as a devil, especially when compared to Gitlab.


GitLab is great - but super fat. The performance will suffer heavily if you don't give it the resources it wants (all RAM you can find, lol).

If you only need Git plus project tracking Gitea is super mature. It runs happily on small VPS.


I prefer Forgejo, but both it and Gitea support actions like GitHub's. You can have a nice CI/CD pipeline that runs 100% in-house, for free. I adore it for personal projects.


> You can have a nice CI/CD pipeline that runs 100% in-house, for free.

Interested! Some detail on how you achieve this for free would be great.


Well, Forgejo’s Actions are very similar to GitHub’s: https://forgejo.org/docs/latest/user/actions/actions/

If you want to run a process after each push to a branch or merge into main or whatever, you describe it in a YAML file in that repo. Configure some workers to run those actions and off you go! I use it for things like running tests and applying Terraform changes.


I understand that part. Mostly interested where the runners are coming from? macOS especially is pretty costly to provide runners for, so who is doing that for free?


You provide the runners on your own hardware. Perhaps a Mac mini would fit the bill?


> Gitea support actions like GitHub's

Citation needed. nektos/act is for sure not "like GitHub's"


Here's Gitea's own comparison to GitHub's Actions: https://docs.gitea.com/usage/actions/comparison

Sure, it's not identical, and no one claims it is. I think it's defensibly like them, though.


We've run Gitea actions (and contributed here and there) for a couple of years, since-by-side with Github. We host in containers on the Gitea side so there are some marginal differences as to what can be run in a job, but our experience has been very positive.


Yes it is. It's not identical, but it is "like" it.


Most of my build config run on either platform (Gitea and Github) interchangeably.


Gitea is neat, and the Actions compatibility is promising. Though I’d suggest a fork, Forgejo: https://forgejo.org/compare-to-gitea/


I want to signal boost the following quote from the URL above:

> Forgejo was created in October 2022 after a for profit company took over the Gitea project. It exists under the umbrella of a non-profit organization, Codeberg e.V. and is developed in the interest of the general public. In the year that followed, this difference in governance led to choices that made Forgejo significantly and durably different from Gitea.

If you take it at face value (at your peril), Gitea is about to start enshittification, while Forgejo will not at any point. My personal opinion, is that this is credible.


isn't that gitlab also for profit company???


They are, and always were. I think we’re more accustomized to it though, and know they won’t try to pull some shenanigans with the CE at least. I guess Codeberg didn’t trust Gitea in the same way when they decided to fork, but I think as a result Forgejo would be more sustainable, them being a nonprofit and all.


Gitlab didn’t arguably and allegedly hijack an established oss brand for their core product.


Thank you for the recommendation.

Will move to that fork in one of my future private infrastructure reconstructions.


I bounced away from Gitea because they don't (last time I checked) have OIDC. I started[0] trying to revive-and-drive a previous PR[1] to add it, but the test failures are beyond my motivation to investigate and resolve.

[0] https://github.com/go-gitea/gitea/pull/33945

[1] https://github.com/go-gitea/gitea/pull/25664


OIDC = OpenID Connect, an open authentication protocol


Gitea's UI is ugly.

While GitHub and GitLab have dedicated design and front-end teams to improve their UI/UX, Gitea and Forgejo aren't large enough to reach that scale, even after Gitea became a company.

For example, look at the number of issues triaged with "UX" [0] or "UX Paper Cut" [1] on GitLab. It is an order of magnitude larger than you would find in any other FOSS option.

[0]: https://gitlab.com/gitlab-org/gitlab/-/issues/?label_name%5B...

[1]: https://gitlab.com/gitlab-org/gitlab/-/issues/?label_name%5B...


Sorry but the GitLab UI was bad, is bad, the whole software feels clunky and slow to use and everything is nested where in comparison Gitea is simple, intuitive and straightforward, just like the old Github days. I also don't know if it's a good sign that there are a lot of UX issues?


I always have a private Gitea instance running for my private projects. VPS are cheap in 2025 and it doesn't eat much resources.


I run Gitea too - Seeing what is happening over at GitHub solidifies my decision.

Not too concerned over my public facing repos, Amazon and OpenAI seem to love 'em! I have the ultimate control over my private repos (nothing juicy). I can't say I trust Microsoft not to do something I don't like at any point in the future.

Edit: I should say I wish phabricator got more love, that was a great tool!


My private repos would contaminate the Copilot LLM for life. Haha.

Have fun Microsoft getting that foul apple out of your system again.


Also heard good things about Forgejo.


That's what gitea is called nowadays. The name changes every few years


They're different projects.

https://forgejo.org/compare-to-gitea/


On the same codebase


Documentation for it looks pretty straightforward; are you doing anything special for security besides a reverse proxy?


If you can put everything behind a Wireguard or other VPN tunnel.


First thing I saw was an annoying Cloudflare captcha.. ugh


Meshtastic works great up to two hops.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: