Re:CasaOS – A simple, easy-to-use, elegant open-source home ...
by xwowsersx on Sunday April 16, 2023 @12:12PM
(#35591306)
I'm not sure about that. Cloud can involve virtualized resources that can be provisioned or deprovisioned dynamically based on demand but, it doesn't necessarily imply that the software / data in the cloud is ephemeral. Both can be designed to be persistent and durable, with long-term storage and retention. I think you're confusing an accident for an essence.
Re:CasaOS – A simple, easy-to-use, elegant open-source home ...
by kjs3 on Monday April 17, 2023 @09:37AM
(#35600502)
Having just gone through certifications for 2 of the 3 big providers, the people who are known for providing cloud services think private clouds are a thing.
Re:CasaOS – A simple, easy-to-use, elegant open-source home ...
by LoganDark on Sunday April 16, 2023 @12:26PM
(#35591456)
my first guess would normally be to look at the shell script[0] and follow along, but it looks like it's not super easy to follow. It's also not very easy to audit, for that matter.
I do see it using its root privileges to force-install packages without prompting (and not even properly—it uses the legacy `apt-get` rather than `apt`—why?), and it's completely unclear that I'd be consenting to this.
Actually, the reason why I don't execute arbitrary code on my machine as root is because it's impossible not to consent to having packages force-installed without prompt.
So the shell script installer grants this app a hard pass for me.
Re:CasaOS – A simple, easy-to-use, elegant open-source home ...
by LoganDark on Sunday April 16, 2023 @12:57PM
(#35591762)
> the easiest method for beginners
Why do people think this way? Honest question.
People create "installers" like these with the goal of making Just One Command that Does Everything For You, saying stuff like "easiest method for beginners". This is suboptimal for many reasons.
I don't want Just One Command that Does Everything For Me. I control the machine; I want to command it myself. This is one of Linux's main selling points. But even for people who don't think this way and just want to install your software quickly, I have concerns.
Providing this installer script as the only way to install your software distribution is actually setting people up for failure:
- Nobody knows how the script works, if it fails they have no way to debug what happened except grepping for log messages in the source code and guessing. At that point just read the whole script and do it manually.
- If the script isn't compatible with their setup, they can't just do the equivalent for their computer, because they might not even know what they need to do. And even if they do figure it out, how will they move on to the next step? They can't just re-run the script if it's not compatible with their setup, remember. Back to reading the whole script and doing it manually.
- The script performs arbitrary changes to their system configuration without asking, like updating repositories(!) and installing dependencies. That's not an OK thing for you to do without asking. And on some rolling-release distributions, like Arch, you never want to update repositories carelessly. Because, if the rest of the system's packages are left outdated after a repository update, they may no longer be compatible with the latest packages available upstream. But you update repositories, on Arch, without telling the user you did so. On Arch, one of the most active rolling-release distributions. So not only will the dependencies you install yourself not necessarily be compatible with the rest of the system—because Arch—random future package installs may also be screwed until the next full system upgrade. Which may never happen if the user never figures out what the problem is.
I sort of lost interest in installing the thing myself, so I never completed my personal audit, but I would recommend, at the very least, not installing packages or updating repositories without prompting first, and also publishing documentation on how to install this without running a fricken' shell script as root, which is not even an acceptable thing to teach "beginners" in the first place. They should be taught not to run things they don't trust, and definitely not to blindly run any shell script from any random website as root.
Sure, it may be 'easy' (for some definition of easy) for 'beginners' (for some definition of beginners) but please don't.
Re:CasaOS – A simple, easy-to-use, elegant open-source home ...
by jasonvorhe on Sunday April 16, 2023 @12:49PM
(#35591677)
Looks like the company running this is simply located in a co-working space in China. Didn't know that just living in China made you a possible PRC asset.
Note - I'm not commenting about whether these guys are PRC assets or not. Or whether there is anything nefarious going on at all. I'm just pointing out that they could be compelled to become assets, even if that's against their wishes.
Re:CasaOS – A simple, easy-to-use, elegant open-source home ...
by dancemethis on Monday April 17, 2023 @12:09PM
(#35602797)
I mean, and all US companies are possible NSA/CIA assets. Which is kinda worse because it was already proven more than once. Snowden and PRISM, anyone?
Re:CasaOS – A simple, easy-to-use, elegant open-source home ...
by mthoms on Monday April 17, 2023 @12:39PM
(#35603207)
Kinda worse? That's highly debatable. It's just a different risk profile. I personally don't expect the US government to take an interest in my activities, but I'm not as convinced about the Chinese for various reasons.
More to your point, as far as I'm aware, individuals can't be forced under law to cooperate with US intelligence. In China, individuals have to cooperate - by law - and the penalties for non-compliance are harsh.
In the case of an open source project maintained by individuals, that's an important consideration.
I do see it using its root privileges to force-install packages without prompting (and not even properly—it uses the legacy `apt-get` rather than `apt`—why?), and it's completely unclear that I'd be consenting to this.
Actually, the reason why I don't execute arbitrary code on my machine as root is because it's impossible not to consent to having packages force-installed without prompt.
So the shell script installer grants this app a hard pass for me.
[0]: http://get.casaos.io/
Oh, nice catch
Why do people think this way? Honest question.
People create "installers" like these with the goal of making Just One Command that Does Everything For You, saying stuff like "easiest method for beginners". This is suboptimal for many reasons.
I don't want Just One Command that Does Everything For Me. I control the machine; I want to command it myself. This is one of Linux's main selling points. But even for people who don't think this way and just want to install your software quickly, I have concerns.
Providing this installer script as the only way to install your software distribution is actually setting people up for failure:
- Nobody knows how the script works, if it fails they have no way to debug what happened except grepping for log messages in the source code and guessing. At that point just read the whole script and do it manually.
- If the script isn't compatible with their setup, they can't just do the equivalent for their computer, because they might not even know what they need to do. And even if they do figure it out, how will they move on to the next step? They can't just re-run the script if it's not compatible with their setup, remember. Back to reading the whole script and doing it manually.
- The script performs arbitrary changes to their system configuration without asking, like updating repositories(!) and installing dependencies. That's not an OK thing for you to do without asking. And on some rolling-release distributions, like Arch, you never want to update repositories carelessly. Because, if the rest of the system's packages are left outdated after a repository update, they may no longer be compatible with the latest packages available upstream. But you update repositories, on Arch, without telling the user you did so. On Arch, one of the most active rolling-release distributions. So not only will the dependencies you install yourself not necessarily be compatible with the rest of the system—because Arch—random future package installs may also be screwed until the next full system upgrade. Which may never happen if the user never figures out what the problem is.
I sort of lost interest in installing the thing myself, so I never completed my personal audit, but I would recommend, at the very least, not installing packages or updating repositories without prompting first, and also publishing documentation on how to install this without running a fricken' shell script as root, which is not even an acceptable thing to teach "beginners" in the first place. They should be taught not to run things they don't trust, and definitely not to blindly run any shell script from any random website as root.
Sure, it may be 'easy' (for some definition of easy) for 'beginners' (for some definition of beginners) but please don't.
https://github.com/pi-hole/pi-hole#method-2-manually-downloa...
I also love the "featured in Hackernews". This post has 9 points as I'm writing this.
It's also been posted to HN a year a go.
Is that what a "cloud" is? Runs containers? Is that obvious?
Interesting, but no, thanks!
Unfortunately, really anything coming out of China might be a PRC asset. We just wouldn't know unless it was too late.
https://www.cnbc.com/2019/03/05/huawei-would-have-to-give-da...
Note - I'm not commenting about whether these guys are PRC assets or not. Or whether there is anything nefarious going on at all. I'm just pointing out that they could be compelled to become assets, even if that's against their wishes.
More to your point, as far as I'm aware, individuals can't be forced under law to cooperate with US intelligence. In China, individuals have to cooperate - by law - and the penalties for non-compliance are harsh.
In the case of an open source project maintained by individuals, that's an important consideration.
https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...