• 0 Posts
  • 32 Comments
Joined 1 year ago
cake
Cake day: July 4th, 2023

help-circle



  • It’s a bit different because of the stated values though.

    Raspberry pi’s foundation is focused on making computers available broadly, while this new organization is focused on making privacy widely accessible.

    While both can be commercialized, the pi’s foundation has no fundamental problems with selling out privacy or focusing on money to achieve those goals. Proton would have a much harder time arguing that profiting from sale.of private data supports privacy.

    This is relevant because it means even if the remaining shares end up on the stock market, the foundation can use its majority ownership to veto any privacy concerns.

    Time will tell. I could also have missed something


  • A company with a public offering basically cannot refuse a large enough buyout because with a public offering comes a financial responsibility to the shareholders. Public stock is a contract saying give me money and I’ll do my best to make you money back, and it’s very legally binding.

    You can avoid this by never going public, but that also means you basically don’t get big investors for expanding what you can offer. A public offering involves losing some of your rights as owner for cash.

    When the legal goal becomes “money above all else”, it is hard to justify NOT selling all the data and violating the trust of your customers for money, customer loyalty has to be monetizable and also worth more.

    Proton has given a majority share to a nonprofit with a legal requirement to uphold the current values, not make money. This means that the remaining ownership can be sold to whoever, the only way anything gets done is if this foundation agrees. It prevents everything associated with a legal financial responsibility to make money, but still allows the business to do business things and make money, which seems to be proton’s founder’s belief, that the software should be sold to be sustainable.


  • Seems solid.

    It doesn’t change a ton, but the point was basically them putting their money where their mouth is and saying “now we can’t sell out like everything else.”

    If you liked them before, this is great. It means google or whoever literally can’t buy them out, it’s not about the money. If you were iffy already because they’re not FOSS or whatever other reason, this doesn’t change that, either, for better or worse





  • In mint I can right click in a folder and reopen the folder with elevated privileges. That’s my primary, I assumed it was standard but if it’s not common I guess it’s a cinnamon thing. If so, maybe cinnamon is the desktop of choice for avoiding the terminal.

    I didn’t do my full diligence to the samba GUI thing, apparently. That’s a good catch.

    To salvage my argument, yumex has a GUI and extends yum, so while the instructions expect the terminal, I think it’ll be optional.

    I still recommend it to nobody, but someone who set out to avoid the terminal doesn’t have to fail.

    yumex, pip-gui, and aptitude give yum, pip, and apt GUI’s, respectively, so most anything that expected the terminal should be doable without it. All it costs is a bunch of effort troubleshooting GUI things or finding out one doesn’t display error messages and logs them weirdly or whatever.


  • Well if i double-click a file I’ve made executable, it will ask if I’d like to run it, and most software will have a github or downloads page that will give you direct downloads to the software.

    In other words, I can successfully install things like a windows user, I just have to go the extra step to open the file’s properties and make it executable with the GUI first.

    Apt is faster, and it’s also faster to do a direct download, make it executable, then execute it in the terminal, too. But I CAN do it.

    Config files can be edited in the GUI text editor, it’s just slower.

    To test my claim and prove your third point, this link is the repository for a samba GUI, found at https://www.samba.org/samba/GUI/. Specifically, it’s SMB4K, the first one.

    Convenient? No. Would it update automatically? No. Do I want to do it this way, or recommend it? Still no. But it does function.








  • The more the code is used, the faster it ought to be. A function for an OS kernel shouldn’t be written in Python, but a calculator doesn’t need to be written in assembly, that kind of thing.

    I can’t really speak for Rust myself but to explain the comment, the performance gains of a language closer to assembly can be worth the headache of dealing with unsafe and harder to debug languages.

    Linux, for instance, uses some assembly for the parts of it that need to be blazing fast. Confirming assembly code as bug-free, no leaks, all that, is just worth the performance sometimes.

    But yeah I dunno in what cases rust is faster than C/C++.


  • According to The arch wiki, x11vnc operates differently than some other servers and is not capable of going headless. You’d need the dummy plug.

    On that same page, though, it lists the alternative to x11vnc as Xvnc, and links to TigerVNC which is capable of going headless, and has an example config for going headless.

    I haven’t tested tigerVNC specifically, but it’s known, so I expect this is the solution to your problem.