Yes, but it's fairly light-touch moderation. Newly registered first packages go through some automatic checks, and if they pass all those checks they are put on a 3-day waiting period for community to give feedback or raise objections to the package, and then at the end of the 3-day period, if nobody blocks it, the package is registered.
One of the automatic checks is a name similarity check, and if the name is too similar to an existing name, then the package is blocked from being auto-merged. At that point, someone will look at it, and there'll be a discussion on whether or not the name is okay. A lot of the time, the response is just "this is a false positive" and the package is greenlit. Other times, there's a discussion on whether or not the name is acceptable, and some alternative suggestions are given.
_______________
There was a little episode recently where someone tried to register a package with the same name as an existing package, but with two letters tacked onto the end of the name. Their package was just a fork of an existing package, but with a minor patch applied becuase they were frustrated that maintainers of the existing package weren't responding to pull requests.
The system automatically flagged the name, and the person was initially upset that they couldn't just register their fork, but within a couple hours we tracked down a maintainer to fix the existing package, and then we added this person as a maintainer to the original package so that they could review and accept pull requests to the package themselves. I think this ended up being a better solution for everyone involved.
It's especially fun once the service is superseded. Guess which one of these services handles MAC address allocation and storage: macaddr_db or atom-util?
Thanks for mentioning this. I built the same thing a year ago for myself in dozen lines of AWK. Looks like great minds think alike :)
In my opinion this is the most practical approach for real world projects. You get benefits like avoiding outdated documentation without huge upfront costs.
How is the bootloader/peripheral compatibility on the non-SBC ARM systems these days? Can you plug in a boot disk on different machine and expect it to just work? My main problem with ARM is that many manufacturers act as if they're special little snowflakes and deserve to have their custom patched kernel/bootloader/whatever.
This is the goal of the Arm SystemReady compliance label. The selection is still pretty limited and what's out there is generally buggy, but there's a few boards out there you can buy like the Orion O6 [0]. If you just want a stable system with predictable performance, you're probably better off with a more traditional system though.
Afaik a lot of bootloaders are proprietary/wonky, a lot of SOCs run custom bootloaders.
However if you do manage to boot things up, hardware with open-source drivers should just work, for example Jeff Geerling has couple of videos on youtube about running his RPi with external AMD graphics cards connected via PCIe, and it works.
You can customize anything, the problem is always how maintainable your customization is. People keep making FrankenDebians (https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_Frank...) using curl|bash install scripts, alternate repositories or just plain brute force symlinking libraries with a hefty dose of chattr +i.
A properly customizable distro allows organizing and tracking patches in layers, etc.
Disabled on most CPUs, plagued by security issues. I haven't used it but I assume debugging would be extremely painful, since any debug event would abort the transaction.
No idea why this was flagged. This is a really good article in terms of both form and content and I was very surprised to learn that the author is actually also a teenager.
I get it, some people dislike the appearance but c'mon, this is HN. If we can use vi(1) on a 80 column terminal, reading an html page is not an impossible task.
reply