#4

Yes! I use it - just make sure you’re using the latest version of it.

Yep! Should do!

I haven’t tried SpiderOak, but you’re spot on with the others - as a flatpak, they will work wonderfully.

#5

@refi64, @ralex and @ketudb: Thank you very much for your feedback! It gave me the confidence to try and install Fedora Silverblue!

Actually: my new laptop arrived today and I installed Silverblue immediately! The installation was just as simple as a normal Fedora installation. So far I haven’t found any problems. Everything seems to work out of the box! I only needed to add Flathub as a repository to Software.

Again: thank you for your feedback!!

Yours sincerely,

Scott Trakker

3 Likes
#6

Hey Scott,

Just so I understand, you installed SpiderOak One and everything is working fine?

#7

Hello Bassclef,

No, I haven’t had the time to install Spideroak so I don’t know if it would work.

Actually, I have to order a new laptop because there something wrong with the screen :frowning: . The new laptop will arrive in two weeks and if everything works well I’m going to install Fedora Silverblue again and after that Spideroak. If it works I can let you know what I did?

Yours sincerely,

Scott Trakker

1 Like
#8

I pretty much agree with everyone’s views and suggestions here on SilverBlue.

The only complaints I have for it is the lack of certain 32bit software support currently. If software like SpiderOak requires some 32bit dependencies, you may be shit out of luck for the time being.

That said, whatever software you can find in the current repo’s you will be able to install more or less in Silverblue. Installing software from 3rd party repos may or may not work due to the lack of 32bit support so your millage will vary.

If this hasn’t been stated already, just install Workstation first, get a SilverBlue VM up and running and start tinkering with the VM directly. Once you get SilverBlue working to your liking and there are no conflicts, blow away your Workstation and replace it with SilverBlue.

Still waiting for the day I can install wine-staging properly so I can switch to Silverblue full-time myself…

#9

Hello Bassclef,

The installation of Spideroak was actually quite easy.

I just followed the steps on the following website:
https://spideroak.support/hc/en-us/articles/115001931926-Installing-SpiderOak-ONE-on-Linux-Without-Software-Installation-Privileges

Only in the last step there is a small mistake:

/home/bob/SpiderOakONE/SpiderOakONE --setup=-

must be

/home/bob/bin/SpiderOakONE --setup=-

Good luck with your installation!

Yours sincerely,

Scott Trakker

#10

Hi everyone, here’s a vague and hand-wavy answer from a humble-end user, i.e. not a developer.

Most of the time I forget that I’m using SilverBlue, and not the normal Fedora experience. However I remember when (1) I try to install something: it looks the same but takes a lot longer; and (2) I try to use command-line software that’s not in the developer toolchain, e.g. LaTeX. Then, sometimes Google helps, and sometimes I just give up.

In relation to LaTeX, I had to install it on another computer I had lying around, then ssh into it, run it & rsync the results back to my main machine. Less than ideal …

1 Like
#11

Have you tried using the toolbox for installing latex?

#12

Yes, I have. And I gave up in frustration.

Thanks for your reply, and sorry for my less-than-helpful response. At some later date I’ll try to report what happened in more detail.

#13

You absolutely cannot expect Silverblue to work like Fedora workstation. If
you don’t want the containerization stuff and the broken package management,
you’re better off with Fedora proper, in my opinion.

#14

I believe it’s unfair to say that Silverblue has broken package management, it’s simply pushing you use a better way to get development dependencies than through the the same package manager that has to deal with system updates.

You can also try and look at something like https://spack.io/

2 Likes
#15

We solved package management in the mid 90s. It is not “better” to bundle
libraries, it’s much worse. This leads to situations such as Windows’ DLL
hell, not to mention the security implications.

1 Like
#16

Because it’s made the system incredibly hostile to developers wanting to write applications for Linux. You can’t guarantee an application written and compiled a year ago will run on a distro version released today.

A lot of packages built for ElementaryOS Loki (0.4) didn’t install nor run on Juno (5.0) because of incompatible package changes (e.g. curl), that is insane and was half their app store.

Linux will avoid breaking userspace at all cost, but userspace will happily break userspace.

Everyone using system level packages could work if library developers did everything possible to avoid breaking backwards compatability, but that just hasn’t happened and I don’t think it’s reasonable to expect them to do so.

5 Likes
#17

I’m sorry, but that is a false premise. It is very easy to write software that
can run on the Linux kernel. We’ve been doing that since the mid 90s as well.

While you can’t guarantee an application compiled a year ago will run on a
distro version released today, that’s fine. It shouldn’t. Recompile it against
the updated libraries.

I have no idea what ElementaryOS Loki and Juno are.

Yeah, it’s called breaking ABI, and it’s fine. Unless it’s proprietary, you
can just recompile it against modern libraries. At worst, you have to either
wait for it to be patched against the new APIs, or just do so yourself. If
it’s in Fedora, you can just wait for the package to be updated.

There’s no reason to avoid breaking backwards compatibility. Keep your
software up to date, and you won’t have that problem to begin with. Keeping
the old versions of everything and bundling it will only lead you to a mess
from a security and stability standpoint.

#18

The kernel is like 10% of what your apps inevitability depend on.

It’s not nearly this simple. What happens when:

  • You depend on a library that endures an major API break, but a downstream distro still ships the old version. Do you maintain both, or maintain the new variant and tell the users of the old variant to deal with it.
  • Downstream patches a dependent library and the behavior inadvertently changes. Do you just hardcode random distros in your build scripts?
  • Want to run your app on a distro libraries or languages, e.g. CentOS? Yes it’s technically possible, yet you haven’t felt pain until you try to make your C++17 code compile and link on CentOS 7.
  • Want to ship experimental / testing versions of your software? Welp, looks like you’re going to be maintaining a couple of PPAs and COPRs. Oh what, a user wants to try a PR that has a fix? They can figure out how to compile it themselves, right?

API breaks can happen quickly, half this “old software” isn’t that old and will be maintained in many distros—and the freedesktop runtimes—for at least another year. The problem comes when half your users are on different sites of a breaking point, or half your users have systems that are just one release too old or too new to use your app.

Real life story: I contribute to an open source game. This game comes from a very old codebase that has used CEGUI for…over a decade. CEGUI 0.8 has been out for several years, yet distro support is spotty or buggy because it’s a library that was designed to be compiled into your software, and we don’t have the manpower to switch now. This dependency alone has resulted in quite a few compilation issues and distro distribution roadblocks. Flatpak is quite possibly one of the best thing’s come to the project from a maintenance standpoint.

6 Likes
#19

Bundling libraries means you can update the version of the library that one application is using without having to update the version for all other applications at the same time. If you do not bundle libraries, you need to either package multiple versions of the library, or delay the update until you have fixed breakage in all of the applications and tested all of them. With equal effort put into updating and testing applications, bundling gets you security updates faster, on average. When bundling reduces security, that is because it does not give maintainers as much incentive to do extra work to update dependencies of other applications that they don’t care about. It is good to focus on increasing efficiency instead of incentivizing people to do more work.

#20

Could someone clarify what happens if a new vulnerability is discovered:

  1. Do we need to upgrade all the bundled packages which use the vulnerable library?
  2. How to solve the issue of increasing the size of the download?
  3. What is the simplest method to determine which bundles are still vulnerable?
#21

[quote=“JohnMH, post:17, topic:1970”]
It is very easy to write software that
can run on the Linux kernel. We’ve been doing that since the mid 90s as
well.
[/quote]

#22

You should be updating the library, for all applications, at once. You do not
need multiple version of the library. On average, bundling gets you no
updates, at all. The libraries that work are thrown in, and then ignored. For
an example of this, see Godot.

#23

In general, security-conscious dependencies are part of the base runtimes, which are maintained by a team of people who keep them updated with security fixes. The existence of runtimes also helps with avoiding duplicates.

2 Likes