Just based on experience in the community and professional experience, I can solidly say that your take on FOSS not being successful is just wrong, and I don’t mean that like you’re stupid or I’m shooting you down, you just wouldn’t realize how huge contributions are unless you know where to look.

Here’s a big example: look how many companies hire for engineers writing Python, Ruby, Rust, Go, Node…whatever. ALL OPEN SOURCE LANGUAGES. You bootstrap a project in any of these, and you’re already looped into the FOSS community. 100% of the companies I have personally worked with and for write everything based on FOSS software, and I can tell you hands down as a fact: never met a single person writing in any closed source IDEs or languages, because very few exist.

If you want to see where all the community stuff happens, find any project on GitHub and look at the “Issues” section for closed tickets with PRs attached. You’ll see just how many people write quick little fixes to nags or bugs, not just on their own behalf, but on behalf of the companies paying them. That’s sort of the beauty of the FOSS community in general in that if you want to build on community projects, you’ll be giving back in one form another simply because, as my last comment said, NOBODY wants to maintain a private fork. Submodules exist for a reason, and even then people don’t want to mess with that, they’d rather just commit fixes and give back. Companies are paying engineers for their time, and engineers committing PR fixes is defacto those companies putting back into the community.

To your Oracle point, I think the biggest thing there you may have been Java. That one is tricky. Java existed long before it was ever open sources by Sun Microsystems, and was available for everyone sometime in the early '00s (not bothering to look that up). Even though it was created by an engineer at Sun, it was always out there and available for use, it just wasn’t “officially” licensed as Open Source for contributions until some time. Sun still technically owned the trademarks and all of that though, and Oracle acquired them at some point, bringing the trademarks under their ownership. There wete a number of immediate forks, but I think the OpenJDK crew was further out in front and sort of won that battle. To this day I don’t know a single Java project using Oracle’s official SDK and tools for that language aside from Oracle devs, which is a pretty small community in comparison, but you’re right in that was essentially a corporate takeover of a FOSS project. How successful it was in bringing people to bear that engagement I think is up for discussion, but I’m sure the community would rightly say “Fuck, Oracle” and not engage with their tooling.

There’s a few different things getting wrapped in here together, so let me break down my take:

1. Licensing - if you intend to only use FOSS software, it wouldn’t matter if a corporate/proprietary version of something exists or not. If you intend to release something and make it free, you would need to include only license-compatible libraries. I don’t see why Microsoft having a proprietary version of something that is better would be a problem, because that’s not the focus of your goal of releasing something for free. Similarly if you start a company and bootstrap a product off of open libraries, you will steer towards projects that are license-compatible. Whether there is a better version is irrelevant.

2. Scope of license - Your comments seem to focus on larger product-complete projects. You mentioned Paint.net as an example. So say Adobe forks GIMP, and drops a bunch of proprietary Photoshop libraries into it to make it beefier or whatever. Similar to the above, people who intend to only use FOSS software still wouldn’t adopt it.

3. Death by license - there have been some cases where FOSS project maintainers get picked up by corporate sponsors and sort of “acquired”. This is on the maintainers to make that choice of course, not the community, and contributing members of that community have every right to be pissed about that. Those contributing members also have the right to immediately fork that project, and release their own as a competitive product. Redis vs Valkey, and Terraform vs OpenTofu, are examples. Some people flock away, some people don’t, but in most cases ts a guaranteed way to turn the community against you, and towards a fork of said project. Happens a lot.

I think what you’re not seeing here is that these companies buying out projects really don’t intend to put a lot of money back into them after they get their bags of money. Whether or not people continue to use the originals is less important than the forks being available and supported. If companies believe in the project, they kick in PRs to keep things rolling along because they need that particular part of their stack. I myself am a maintainer in multiple public projects, and also work with companies that contributed to dozens of different public projects because the products they make revolve around them: everything from ffmpeg, to the torch ecosystem. You find a bug you can fix, you submit a PR. That’s what keeps this ecosystem going.

Smaller scale startups to mid-sized companies contribute all the time to public projects, though it may not be apparent. Larger corporations do as well, but it’s more of legal thing than an obligation to the community. Rewriting entire batches of libraries isn’t feasible for these larger companies unless there is a monetary reward on the backend, because paying dev teams millions of dollars to rewrite something like, I don’t know, memcache doesn’t make sense unless they can sell it, and keeping an internal fork of an open project downstream is a huge mess that no engineer wants to be saddled with.

Once a public project or library is adopted, it’s very unlikely to be taken over by corporate interests, and it’s been that way for almost fifty years now (if we’re going back to Bell and Xerox Labs). Don’t see that changing anytime soon based on the above, and being in the space and seeing it all work in action. Though there are scant cases, there’s no trend of this becoming more prevalent at the moment. The biggest threat I see to this model is the dumbing down of engineers by “AI” and loss of will and independent thought to keep producing new and novel code out in the world.

Check the rest of the thread 🤣

People in here don’t work in the space, and are clearly not knowledgeable about the subject. They can downvote me all they want.

What does security have to do with open-source projects succumbing to “corporate takeover”, which isn’t even possible?

If the code is of such a restrictive license that you aren’t able to fork and re-release it with changes, then it isn’t open-source to begin with.

To your last point about removing “old features”, this is done all the time, and this is why things use semantic versioning. Nobody wants to be forced to maintain old code into perpetuity when they can just drop large portions of it, and then just release new versions with deprecated backends when needed

What you’re describing is not a two-way sync then. You’re expecting this to be an actual database, but it’s just a flat file with XML at its core. Here’s the file format specification .

Best you can do is set frontend options to prevent accidental deletions, and keep lots of backups, or put it on a versioning storage backend.

You may want to switch to a different solution if this is your desired use-case.

Removed by mod

deleted by creator

Any OS with no password is insecure. Hands down.

Linux/Unix has a permissions structure that works at the filesystem level, to be really brief about it.

Files are owned by users. Users can be part of groups to represent a larger number of users for simple organization.

Regular users can only touch files they own, or are owned by a group they are in. Root has master permissions to anything.

As a regular user, your home directory is owned by you. Anything you create is owned by you. All programs executed by you require that you have permissions to those things. Therefore if you’re just bouncing on the system and doing things, you can only harm the files that you own.

Your account having a password prevents access to this account. Though it’s a regular user, anyone with that password can harm your files.

The Root password allows anyone to execute or delete any files on the system. Anyone with this password can get to any file on the system, so you never let anyone know this password.

Your assumption that SSH somehow has different passwords is incorrect. You make a user on a machine and you don’t prevent SSH access…then they can SSH in, but they’re still a regular user.

They aren’t going to make their own desktop. That’s just not gonna happen. They’ll use KDE as before, and that’s just the facts. I’m not saying they will make anything other than a VR-style compositor to select standard 2D virtual desktops. That’s simple and effective, and doesn’t require building a whole new thing.

This should sidestep that and timeout pretty quickly: https://jshtab.github.io/guide/gvfs-autmount/

Not sure you’re getting it…

SteamOS runs KDE desktop. Frame will also have KDE Desktop, be use it’s just running the ARM build of the same SteamOS that will be on all of these devices.

Making a VR-reaey compositor display for this is fairly simple after this point, you just need to hook all the sensors into camera movement for the screen, and that screen can show many composite views…like the desktop, or a media screen, or the Steam Library.

It’s a basic function of VDD. It will definitely be in there.

Try going into your BIOS settings and disabling IOMMU for the USB and Chipset settings. Boot and see if it works then.

Your North and South (if you have one )bridge chip?

Open your machine and look at these ports.

Are they directly connected to the motherboard, or on the front of a case extended by a cable?

It’s not “trouble” if you’re already familiar with Linux. It’s not the way I would go as a user of 20+ years, but it’s not just for desktop use.

If you’re looking to build a platform for something, it’s perfect. Look at why Valve switched to use to for SteamOS. You have an underlying framework of a stable system, and you just create automation to slap it all together into the base layer of all the things you want without having to worry about specific things breaking the stack you’re building on top of it.

It’s like a blank page instead of a notebook with line guides.

It helps make more sense if you think of everything you’ve got to build on it already existing in a git repo. Merge > Build > Release. Makes perfect sense, and you save yourself creating an entire distro to maintain from scratch.

99% of all Windows games running Proton, and most perform better than on Windows, depending othe game.

For the specific games you mentioned, they all have Platinum rating in Proton, meaning flawless. You can see here in ProtonDB.

I’m not sure what your experience was in the past, but I write tons of Proton patches for games, and the only ones I’ve seen that don’t play well are the pre-DirectX9 games, which can’t plan on Windows XP or later anyway. Proton will soon be able to play these games without issue thanks to some Vulkan patches coming up.

That’s slightly different. That is mapping controllers to already existing inputs for a game, which steam-input already does.

Mapping all the sensors of a VR headset for motion and tracking is an entirely different thing, though kinda similar in some sense.

They’ve already said they’ll be using FEX: https://www.pcgamer.com/hardware/vr-hardware/steamos-launching-for-arm-fex-translation-layer/

Well it’s not going to suddenly be all VR’d up or anything 🤣

Part of the reason I would imaging they implementing a new kind of steam-input layer for VR is for things like a theater mode and desktop. I could see them making some sort of a simple hook for view controls in games for your exact scenario, but that would be heavily dependent on the game having something like free look already be possible, and then the developers just write a quick patch of a couple lines to hook the steam-vr-input hook into their code, and BAM.

It wouldn’t need to. They would just need to include a virtual desktop manager or interface to render the usual compositor in a VR sort of way. That’s why I put it in the list. Same thing that would make a theater mode would also allow a desktop to render in a space on a VR compositor.