Sorry if I came across negative; it was more my intent to paint motivations as a positive thing. All these projects definitely learn from each other, and different priorities bring new approaches. I think it's how the industry moves forward, but I can see how my phrasing might be read as dismissive. Not my intent at all!
The aquilles heel of package managers isn´t consistency, but lack of packages.
I appreciate the benefit of distro-agnostic package management, but unless you rely on a portable toolchain, or distribute statically linked binaries exclusively, we fall short from the panacea of portability (many other options available, yes, but packages are needed!)
I have personally leveraged pkgin[1] for consistency. I can simply drop pkgsrc[2] in my home directory and use the same tools in *bsds, smartos, linux, macos and cheese.
To address your concerns:
1. Yes, no portable toolchains or any other kinds of dependencies are required.
2. Each & every single binary is statically compiled. This is the core at philosophy of Hysp. A single binary that runs anywhere.
3. Currently, there's about 200 pkgs for x86_64 & arm64 each. The upstream source (https://github.com/Azathothas/Toolpacks) has over 400 for x86_64 & 300+ for arm64, which will slowly be added to Hysp-Pkgs.
4. As installing random binaries from random sources is not advisable due to security concerns, the pkg-source can be self-hosted by anyone and hysp can be configured to use that instead of the default source.
Hey, thanks for replying! I had missed the static binary detail, and it is by far the most sensible solution.
Regarding the packages, those are very respectable numbers... But who is maintaining them? It takes a lot of effort to maintain a repo up to date, with patches both functional and security related. This is in most distros a full time job for a group of people. For comparison pkgsrc has 19444 packages, and it takes a substantial effort to keep up to date.
Regarding 4... I am not sure about your angle there... "Running random binaries" is risky. Technically hysp is a random binary itself, from a random source. I don´t know who you are, and even in that case any certification of authority is best efforts. You can´t certify that the code you built has not been compromised... This is a tough problem, good ideas are still needed!
OTOH, maybe you could leverage the work of the pkgsrc team to increase the number of available packages, traceability, and portability!
Join forces!
Synergy!!!!
Regarding pkgsrc, we came across that and the reason we eventually ended up creating hysp was that we didn't want to use any dependencies what's so ever.
So if you wanted to, you could use pure bash and nothing else to parse the TOML files that hysp uses and do everything that it does.
Hysp is simply an abstraction over that philosophy.
As to the question of maintaining them, currently only I am.
Hysp is a small project for now, and we have no plans to add anything that's dynamic. This will ensure low numbers of packages, but guarantee that those packages will work anywhere.
So maintaining the PKGs is quite simple, I write custom build script for each of them and then GitHub Actions automates the rest.
This currently requires very little manual maintenance.
The following repos are where the current packages are sourced from:
I had to mention 4, because people kept asking us about security concerns.
Self-Hosting everything on your own server and using hysp just as the frontend, is an option for those people.
Gentlepeople! Remeber people have opinions, like they have fingers to type them...
These could be red flags for the author, I respect that. These are not universal, yet they could be good conversation starters.
Consider that if you don't hear the answer that you expect, maybe you can contribute something of great value to the company... Or receive a lesson on the complexities of a particular business.
Also, language-itis itself can be a problem. We love the shiny, and forget the old... I am not saying that punch cards and FORTRAN are the tool of the future, but maybe FORTRAN is the right tool for a specific problem...
I don't know if you have noticed... But programming languages could potentially mean very little, soon.
Saying "apprehension towards containers is a red flag" is as subjective as the apprehension itself. I like to work with professionals that have a justified opinion, rather than knee jerk reactions.
I am old, I've seen it all, sometimes I use containers. Are they useful? Sure! Are they "the final form"? No!
Tools are just tools, don't get obsessed about them... They only matter when used properly to solve the right problem. Obsession about tooling generates so much waste... and burnout!
While I can imagine such a scenario, and there is a resting area with coffee and food in many datacenters... You weight the same when you get into the cage with coffee in your belly, and when you are getting out because it percolated to your bladder.
Having said that, I've seen some places where the security measures are placed due to a listed requirement, but miss the point that they have.
Finally, data is definitely THE most valuable good, but also confidential hardware, that fits in your pocket!
edit: saw a typo!
Think about what you're saying. Texas didn't suddenly lose generation capacity that day. Their generation failed to work because it was frozen - and let's be clear: it was the natural gas plants that were the problem. The Texas legislature incentivizes utilities to not winterize their plants, so they don't.
At the time Texas was dealing with frozen power plants there were plenty other colder parts of the country that had their generation, including windmills, running just fine. Let's not pretend the lack of generation capacity caused the problem, because it didn't.
Yes, thermal power plants need a cold and hot end to operate, and they are designed to operate within the thermal "range" that its location can provide + some error. Now, this is not really a limitation, rather an engineering constraint. Thermal cycles can be stretched with multiple devices such a HRSG, in the case of combined cycles.
About powerplants in France shutting down because of cooling during the summer... I find it hard to believe this is a widespread issue, if an issue at all. Many of the existing nuclear reactors are reaching an age where massive maintenance schedules need to be executed. If the problem is extending the thermal range, that's relatively easy to fix.
I think the issue is more not killing everything in the river the warmer water is released back into, so the temperature differential becomes unworkable at certain intake temperatures.
I agree with the intention. This has been part of the design constraints of a plant for at least 30 years... I reckon it is possible older plants didn't take steps to cool down the open water loop, but it is indeed relatively straight forward to tackle: cooling towers, open air reservoirs, and again heat exchangers...
It's not an easy thing to retrofit into an existing plant though: first of all France isn't the US and even though it's the biggest country in western Europe, it's relatively space constrained, especially in the places where plants are built, so most exiting sites are already quite cramped (even just post-Fukushima external diesel generators gave headache to my wife's colleagues in her plant site). Also in France we have a lot of reactors, on very few rivers (Rhône and Loire river have like a dozen reactor on each) so there's less margin than what we'd like.
My point is that thermal power doesn't scale well. If you need 10x more electricity (growing needs plus electrification of all energy) thermal pollution of rivers becomes a big issue.
I am just stopping by to say that this is actually a thing. It is called hesiod and works great in small, maybe air-gapped networks.
As a side note, anything security related exists in the reality of uncertainty. It is expected that sharing properly secured secrets is reasonably safe, but day after day we discover "we didn't know". Sometimes simplicity for a particular application is worth certain amount of risk.
Sometimes, you need to take the server out of its box, out of the bunker, and plug it to both the power distribution network, and of course... a LAN...
Hesiod was actually a thing. I'm not aware of anyone who has run it in production in the last 20 years, perhaps you are? But, in any event, password technology was immature and insecure then (i.e. RMS got upset when passwords were introduced, or remember how easy it was to crack 3DES in /etc/passwd so /etc/shadow came to be).
It's even worse now, even on an air-gapped network, because the underlying insecurity is still within DNS. DNS would make a great highly-scalable authn DB for non-UNIX accounts (not in the Hesiod sense, but more in the modern web-app sense), except for all of the other high-scalable and secure authn DB's that aren't built on top of woefully insecure tech.
> It is expected that sharing properly secured secrets is reasonably safe
As you know, though, this is why Diffie and Hellman invented public key exchange -- because sharing secrets, even properly secured, is actually not reasonably safe at all in most circumstances. Even if you secure the secret, it's the communication of those secrets during the sharing where everything breaks down. (https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exc...)
This is of course because a secret is not a secret as soon as you share it with someone else. Instead, DH designed their key exchange to have a private key, that only you know, and a public key that you can share. Each party can derive a shared key using the other's public key, but only they each know their private key.
> Sometimes, you need to take the server out of its box, out of the bunker, and plug it to both the power distribution network, and of course... a LAN...
Even though perfect security is obviously impossible, it's still worth striving for. Relying on DNS for more than absolutely necessary is choosing to rely on technology that began without any thought to security and ended up with a history of massive, Internet-wide vulnerabilities. (See elsewhere in the thread for a great Wired article on Dan Kaminsky's successful attack on all of DNS.)
[1] https://en.wikipedia.org/wiki/Jeskola_Buzz