Kata1yst

When it’s a documented scientific process and it’s scaled up and used in the real world to displace the other methods, I’ll be ready to acknowledge hydrogen as a valid part of energy infrastructure.

Nope! And most hydrogen is fossil fuel (methane) derived and horribly energy inefficient. At this point it’s green washing at best.

Edit: adding data:
Steam-Methane Reforming (SMR) accounts for about 95% of all hydrogen production on earth. It uses a huge amount of heat, water, and methane to produce hydrogen.

https://en.m.wikipedia.org/wiki/File:SMR%2BWGS-1.png

For inputs:

• 6.2MWh of Heat
• 2.2 tons of Methane
• 4.9 tons of pure water

The outputs are:

• 6 tons of CO2
• 1.1 tons of H2

The overall energy in vs energy out is at most 85% efficient. https://www.sciencedirect.com/science/article/abs/pii/S0016236122001867

Hydrolysis, the main competing method, and the one most touted by hydrogen backers, accounts for about 4% of hydrogen production.
This method takes in only pure water and electricity, but it’s efficiency is abysmal at some 52%. In every case, a modern kinetic, thermal, or chemical battery will exceed this efficiency.

Other methods are being looked into, but it’s thermodynamically impossible for the resulting H2 to produce more energy than it takes to create the H2. So at best today we could use H2 as a crappy battery, one that takes a lot of methane to create.

That’s called ‘privilege escalation’, and replacing system level calls with user level calls is closely watched for and guarded against with many different security measures including SELinux.

You’ve already outed yourself multiple times in this thread as someone who doesn’t understand how security in the real world works. Take the L and try to learn from this. It’s okay not to understand something. But it’s very important to recognize when that happens and not claim to understand better than someone else.

I strongly disagree with your premise. Separating authentication and privilege escalation adds layers of security that are non-trivial and greatly enhance resilience. Many attacks are detected and stopped at privilege escalation, because it happens locally before a user can stop or delete the flow of logs.

If I get into your non-privileged account I can set up a program that acts like sudo

No you cannot. A non privileged user doesn’t have the access necessary to run a program that can accomplish this.

And even if they do it’s too late anyway because I’ve just compromised root and locked everybody out and I’m in there shitting on the filesystems or whatever. Because root can do anything.

Once again, you didn’t privilege escalate, because once you have a foothold (authentication) you don’t have the necessary privileges, so you must perform reconnaissance to identify an exploitable vector to privilage escalate with. This can be any number of things, but it’s always noisy and slow, usually easy to detect in logs. There is a reason the most sophisticated attacks against well protected targets are “low and slow”.

And if I can’t break into your non-privileged account then I can’t break into a privileged account either.

You’re ignoring my points given regarding the risks of compromised keys. If there are no admin keys, there are no remote admin sessions.

These artificial distinctions between “non-privileged” and “superuser” accounts need to stop. This is not good security, this is not zero trust. Either you don’t trust anybody and enforce explicit privilege escalation for specific things, or just accept that you’re using a “super” paradigm and once you’ve got access to that user all bets are off.

Spoken like someone who has never red teamed or purple teamed. Even admin accounts are untrusted, given only privileges specific to their role, and closely monitored. That doesn’t mean they should have valid security measures thrown away.

Wouldn’t separate SSH keys achieve the same?

Separate ssh keys for the user and the admin? Yeah, see point 2, admins should not be remotely accessible.

Really? How, exactly? Break the ssh key authentication? And wouldn’t that apply to all accounts equally?

Keys aren’t perfect security. They can easily be mishandled, sometimes getting published to GitHub, copied to USB drives which can easily be lost, etc.

Further, there have been attacks against SSH that let malicious actors connect remotely to any session, or take over existing sessions. By not allowing remote access on privileged accounts, you minimize risk.

Forcing a non privileged remote session to authenticate with a password establishes a second factor of security that is different from the first. This means a cracked password or a lost key is still not enough for a malicious actor to accomplish administrative privileges.

A key is something you have

A password is something you know

So, by not allowing remote privileged sessions, we’re forcing a malicious actor to take one more non-trivial step before arriving at their goals. A step that will likely be fairly obvious in logs on a monitored machine.

On a server, it allows you to track who initiates which root season session. It also greatly minimizes the attack surface from a security perspective to have admin privileged accounts unable to be remotely connected to.

They even literally have a section of the article that says they “see Fair Software as an alternative model to the free and open source software model”, and they think it’s superior because the “developers can profit”.

Newsflash: the developers usually see fractions of those cents while most of the money goes to the management and shareholders of the company that employs them. Hmm, doesn’t seem fair to me.

Also, developers can and do profit from FOSS in many ways, but the most popular models are with commercial support, SaaS offerings, and additional functionality (like providing a web interface, clustering manager or other external piece of the puzzle to solve the problem at scale in enterprise).

Like you said so succinctly: propaganda website to make rug pullers like Elastic and Hashicorp look better.

deleted by creator

Accurate, but not bad, yes. It turns out standardized base systems and ABIs are important to an ecosystem.

Linux tried the disorganized free-for-all for two decades, and what we got was fragmented “Ubuntu admins”, “debian admins”, “redhat admins”, “suse admins”, and a whole shitload of duplicated effort in the packaging ecosystem, only for half the packages out there to be locked to Ubuntu or RHEL. So the corporate interests, and a fair number of the community efforts, centralized their problems and solutions into a small standardized suite in Mesa+Wayland+systemd+Pipewire+flatpak, etc

The result is a ton more interoperability, a truly open ecosystem where switching your distro doesn’t mean hiring different people and using different software, and a lot more stability and maturity.

And hey, if a user or distro wants to do their own thing, they can make and own their niche, same as before. Nothing lost.

It’s been kind of wild to watch over the past 15 years or so, makes me very hopeful for the next 15.

No no you don’t understand. The evil corporate overlords abused their power to force a choice on a developer, even though that choice was objectively the right choice and the developer was throwing a tantrum.

This is truly awful. We must not let evil corporations, no matter their credentials, expertise, and decades of beneficial partnership with open source, tell immature and short sighted developers how to develop.

I use FreshRSS. Can’t say I love the interface, but with the open and standardized API, there are dozens of beautiful front ends to choose on any device.

For real? Damn it that’s going to be painful.

If you’re trying to use it as a workstation or a laptop, you won’t find much compelling. It’s built with the intent to act as a server. In fact, as a web server or networking server it’s second to none.

Administrating BSD is lovely. It’s well documented and everything is very stable, understandable, and predictable.

“We had a huge chunk of our engineering staff spending time improving FreeBSD as opposed to working on features and functionalities. What’s happened now with the transition to having a Debian basis, the people I used to have 90 percent of their time working on FreeBSD, they’re working on ZFS features now … That’s what I want to see; value add for everybody versus sitting around, implementing something Linux had a years ago. And trying to maintain or backport, or just deal with something that you just didn’t get out of box on FreeBSD.”

I still hold much love for FreeBSD, but this is very much indicative of my experience with it as well. The tooling in FreeBSD, specifically dtrace, bhyve, jails, and zfs was absolutely killer while Linux was still experiencing teething problems with a nonstandard myriad of half developed and documented tools. But Linux has since then matured, adopted, and standardized. And the strength of the community is second to none.

They’ll be happier with Linux.

https://en.wikipedia.org/wiki/HTTP%2F3?wprov=sfla1

I was actually surprised to find out QUIC is fairly close to being default.

Wikipedia

HTTP/3 uses QUIC, a multiplexed transport protocol built on UDP.

HTTP/3 is (at least partially) supported by 97% of tracked web browser installations (thereof of 98% of “tracked mobile” web browsers), and 29% of the top 10 million websites.

Never ask a man his pay, a woman her weight, or a data horder the contents of their stash.

Jk. Mostly.

I have a similar-ish set up to @Davel23 , I have a couple of cool use cases.

• I seed the last 5 arch and opensuse (a few different flavors) ISOs at all times

• I run an ArchiveBot for archive.org

• I scan nontrivial mail (the paper kind) and store it in docspell for later OCR searches, tax purposes etc.

• I help keep Sci-Hub healthy

• I host several services for de-googling, including Nextcloud, Blocky, Immich, and Searxng

• I run Navidrome, that has mostly (and hopefully will soon completely) replace Spotify for my family.

• I run Plex (hoping to move to Jellyfin sometime, but there’s inertial resistance to that) that has completely replaced Disney streaming, Netflix streaming, etc for me and my extended family.

• I host backups for my family and close friends with an S3 and WebDAV backup target

I run 4x14TB, 2x8TB, 2x4TB, all from serverpartsdeals, in a ZFS RAID10 with two 1TB cache dives, so half of the spinning rust usable at ~35TB, and right now I’m at 62% utilization. I usually expand at about 85%

these toy OSs don’t solve day to day problems the way that Windows, Mac, and Linux did when they first came to market.

Yes, this is the exact point I made in my first post. And in depth in my response.

Disingenuous how? You don’t think Linux solved a real day to day need of it’s first users?

Sure, from Torvald’s perspective, it was a project specifically to solve a small problem he had. He wanted to develop for a nix platform, but Minix wouldn’t work on his hardware, and the other *Nixs were out of reach.

And this was generally true in the market as well. Linux arrived just in time and was “good enough” to address a real gap, where Minix was limited in scope to basically just education, Hurd was in political development hell, and the other Nixs were targeted at massive servers and mainframes. Linux filled the “*Nix for the rest of us, inexpensively” niche, eventually growing in scope to displace its predecessors, despite their decades of additional professionalism and maturity.

That niche is now filled, the gap no longer exists. A “New Linux” wouldn’t displace Linux, because the original already suits the needs we have well enough. This is precisely why the BSDs and Solaris were “too little, too late”. They were in many ways better than Linux, but the problems they solve compared to Linux are tiny and highly debatable. Linux addressed a huge, day to day need of people who were motivated to help.

Yeah exactly. Toy OSs have only increased in scope, scale, and number. And the public is still completely unaware, because these toy OSs don’t solve day to day problems the way that Windows, Mac, and Linux did when they first came to market.