5 ms·

> Apple/Google isn't going to try and steal your identity, bank account info, or numerous other "small" things You can believe in that, and trust them, but you

by drran 5y ago

> Apple/Google isn't going to try and steal your identity, bank account info, or numerous other "small" things You can believe in that, and trust them, but you cannot prove that, unless you have access to the source of everything installed by Google/Apple, and source of third party apps, favored by Google/Apple. But, even if you're working for a government agency and have access to sources, it's still a monumental task to do, because of the volume of the sources. It's why we, Linux owners, were crying when trivial initd and trivial shell scripts, which are easy to read and understand in about an hour or two, were replaced by Systemd, which may take days just to read source.

google234123 5y ago
> Linux owners, were crying when trivial initd and trivial shell scripts, which are easy to read and understand in about an hour or two, were replaced by Systemd Nah, most Linux owners didn't care and the fact that the most distribution voted with their feet to switch should say enough. Also, full init script were not trivial.
- MereInterest 5y ago
  Most people don't care about plumbing until it breaks and spews sewage water all across the apartment, after which they'll start having some pretty strong opinions about types of pipes. I didn't care about systemd until its default configuration deliberately broke emacs daemon and tmux, after which I had some pretty strong opinions about systemd. At this point, every distribution disables that setting, but it shows that systemd's developers cannot be trusted to make reasonable defaults, and must be double-checked to avoid blatant foolishness.
  - SilverRed 5y ago
    Been using systemd for a very long time now and have had no issues. Had a very pleasant time setting up services to start on boot and such. And you can't just pull out "Yeah but it might break sometime in the future" because it never has broken for me, and that same argument can be used against literally every thing in existence. The vast majority of linux users have very positive experiences with systemd and it's cli tools are very good.
    - MereInterest 5y ago
      In this case, the only reason that it didn't break more widely is because the adults in the room overrode the default KillUserProcesses=yes at the distribution level. This isn't an argument about whether something "might break in the future", as you so kindly put words into my mouth. This is an argument that I do not trust the systemd developers to make reasonable choices, as they have shown a willingness to break long-standing standards for benefits that are marginal at best. Discussion at the time: https://news.ycombinator.com/item?id=11797075 https://news.ycombinator.com/item?id=11797075 Continued defense of the decision as January 2019: https://news.ycombinator.com/item?id=19023232 https://news.ycombinator.com/item?id=19023232
      - lavabiopsy 5y ago
        KillUserProcesses=yes is quite a reasonable default for security though, as lingering processes after logout can be an issue on multi-user systems. For example it can be used as protection against fork bombs. I actually have no idea how Linux persisted for so long without something like that, it seems the long-standing standard here was not great. Rememeber that a lot of what a service manager has to do is decide what policies to set based on what security is provided by the kernel, so in some cases all they can do is provide an option and try to set that to the most secure default. I tried to read those threads but I couldn't really gather much information, a lot of the rhetoric is pretty extreme and outrageous. I would suggest to avoid ad hominem comments about "adults in the room" and such, as it distracts from your argument. (more reading on this subject here http://www.paulgraham.com/disagree.html http://www.paulgraham.com/disagree.html)
        MereInterest 5y ago
        Multi-user systems are exactly the use case that makes KillUserProcesses=yes unsuitable as a default. Control groups are good for stability, because as you say, you can manage resource quotes, or kill an entire forkbomb. However, KillUserProcesses goes a step further, and also kills processes whenever there is a network failure. KillUserProcesses only makes sense in a single-user environment, where logging out is an active decision from the user. Typically, logging out (intentionally or through dropped connection) sends SIGHUP to the active process, then recursively to all children. If SIGHUP is explicitly caught, then the process continues to live. With systemd defaults, logging out sends SIGKILL to processes, unless they they were started with "systemd-run --scope --user $PROCESS". In both cases, programs can persist, so there isn't a security benefit. However, one removes portability because it requires calling a systemd binary or linking against a systemd library, rather than being part of the POSIX standard. The short-term benefit of KillUserProcesses=yes is that programs that erroneously request to be long-lived remain alive. The short-term drawback is that programs that correctly request to be long-lived are killed. The long-term benefit of KillUserProcesses=yes is nil, because programs can still erroneously request to be long-lived. The long-term drawback is increasing dependence on systemd internals, code complexity, and lack of portability. In both short and long term, the drawbacks massively outweigh the benefits. The vitriol received in those threads was in large part due to systemd developers not recognizing those drawbacks. From their comments, requesting to be long-lived through the standard POSIX method is a hack, allowing the short-term drawbacks to be dismissed, and that a hard dependency on systemd libraries is not a long-term drawback. With regard to my tone, perhaps I should have combined my two comments in this thread into a single one. The distributors being the adults in the room and overriding the systemd default was intended as a conclusion, to more fully describe an appropriate view toward the systemd developers. However, it appeared at the start of my second comment, and so I can see how it would appear as an attack rather than as a conclusion.
gnopgnip 5y ago
Apple, Amazon, Google are not going to steal your credit card, identity, bank account info because you could sue them, and because consumer protections agencies would pursue them. The same is not true if you buy a no name tablet with malware pre loaded
- baybal2 5y ago
  > Google are not going to steal your credit card ... Last time somebody tried to sue Google for billing them for some random game, it didn't work out that well
  - google234123 5y ago
    Nice shifting of the goal posts
- hulitu 5y ago
  They will not try to steal it because they have it. Check what analytics has the page where you make payments. Check your browser settings (passwords, credit card data).
cyanydeez 5y ago
if we had to prove technological safety in the modern day world we would all go live in caves. unfortunately, thats a strawman position.
lavabiopsy 5y ago
>Linux owners, were crying when trivial initd and trivial shell scripts, which are easy to read and understand in about an hour or two, were replaced by Systemd, which may take days just to read source. Not sure I understand why you would cry about that, systemd is actually not a very complex project if you're used to low level C daemons. The most complicated part is the d-bus portions, but those are mostly a lot of boilerplate, and you should be understanding it anyway if you use a modern system with d-bus. Trivial initd and trivial shell scripts are also lacking in quite a bit of functionality compared to systemd, at least in my experience those would tend to grow until they became brittle and unmaintanable.

by drran 5y ago

google234123 5y ago

> Linux owners, were crying when trivial initd and trivial shell scripts, which are easy to read and understand in about an hour or two, were replaced by Systemd Nah, most Linux owners didn't care and the fact that the most distribution voted with their feet to switch should say enough. Also, full init script were not trivial.

MereInterest 5y ago
Most people don't care about plumbing until it breaks and spews sewage water all across the apartment, after which they'll start having some pretty strong opinions about types of pipes. I didn't care about systemd until its default configuration deliberately broke emacs daemon and tmux, after which I had some pretty strong opinions about systemd. At this point, every distribution disables that setting, but it shows that systemd's developers cannot be trusted to make reasonable defaults, and must be double-checked to avoid blatant foolishness.
- SilverRed 5y ago
  Been using systemd for a very long time now and have had no issues. Had a very pleasant time setting up services to start on boot and such. And you can't just pull out "Yeah but it might break sometime in the future" because it never has broken for me, and that same argument can be used against literally every thing in existence. The vast majority of linux users have very positive experiences with systemd and it's cli tools are very good.
  - MereInterest 5y ago
    In this case, the only reason that it didn't break more widely is because the adults in the room overrode the default KillUserProcesses=yes at the distribution level. This isn't an argument about whether something "might break in the future", as you so kindly put words into my mouth. This is an argument that I do not trust the systemd developers to make reasonable choices, as they have shown a willingness to break long-standing standards for benefits that are marginal at best. Discussion at the time: https://news.ycombinator.com/item?id=11797075 https://news.ycombinator.com/item?id=11797075 Continued defense of the decision as January 2019: https://news.ycombinator.com/item?id=19023232 https://news.ycombinator.com/item?id=19023232
    - lavabiopsy 5y ago
      KillUserProcesses=yes is quite a reasonable default for security though, as lingering processes after logout can be an issue on multi-user systems. For example it can be used as protection against fork bombs. I actually have no idea how Linux persisted for so long without something like that, it seems the long-standing standard here was not great. Rememeber that a lot of what a service manager has to do is decide what policies to set based on what security is provided by the kernel, so in some cases all they can do is provide an option and try to set that to the most secure default. I tried to read those threads but I couldn't really gather much information, a lot of the rhetoric is pretty extreme and outrageous. I would suggest to avoid ad hominem comments about "adults in the room" and such, as it distracts from your argument. (more reading on this subject here http://www.paulgraham.com/disagree.html http://www.paulgraham.com/disagree.html)
      - MereInterest 5y ago
        Multi-user systems are exactly the use case that makes KillUserProcesses=yes unsuitable as a default. Control groups are good for stability, because as you say, you can manage resource quotes, or kill an entire forkbomb. However, KillUserProcesses goes a step further, and also kills processes whenever there is a network failure. KillUserProcesses only makes sense in a single-user environment, where logging out is an active decision from the user. Typically, logging out (intentionally or through dropped connection) sends SIGHUP to the active process, then recursively to all children. If SIGHUP is explicitly caught, then the process continues to live. With systemd defaults, logging out sends SIGKILL to processes, unless they they were started with "systemd-run --scope --user $PROCESS". In both cases, programs can persist, so there isn't a security benefit. However, one removes portability because it requires calling a systemd binary or linking against a systemd library, rather than being part of the POSIX standard. The short-term benefit of KillUserProcesses=yes is that programs that erroneously request to be long-lived remain alive. The short-term drawback is that programs that correctly request to be long-lived are killed. The long-term benefit of KillUserProcesses=yes is nil, because programs can still erroneously request to be long-lived. The long-term drawback is increasing dependence on systemd internals, code complexity, and lack of portability. In both short and long term, the drawbacks massively outweigh the benefits. The vitriol received in those threads was in large part due to systemd developers not recognizing those drawbacks. From their comments, requesting to be long-lived through the standard POSIX method is a hack, allowing the short-term drawbacks to be dismissed, and that a hard dependency on systemd libraries is not a long-term drawback. With regard to my tone, perhaps I should have combined my two comments in this thread into a single one. The distributors being the adults in the room and overriding the systemd default was intended as a conclusion, to more fully describe an appropriate view toward the systemd developers. However, it appeared at the start of my second comment, and so I can see how it would appear as an attack rather than as a conclusion.

gnopgnip 5y ago

Apple, Amazon, Google are not going to steal your credit card, identity, bank account info because you could sue them, and because consumer protections agencies would pursue them. The same is not true if you buy a no name tablet with malware pre loaded

baybal2 5y ago
> Google are not going to steal your credit card ... Last time somebody tried to sue Google for billing them for some random game, it didn't work out that well
- google234123 5y ago
  Nice shifting of the goal posts
hulitu 5y ago
They will not try to steal it because they have it. Check what analytics has the page where you make payments. Check your browser settings (passwords, credit card data).

cyanydeez 5y ago

if we had to prove technological safety in the modern day world we would all go live in caves. unfortunately, thats a strawman position.

lavabiopsy 5y ago

>Linux owners, were crying when trivial initd and trivial shell scripts, which are easy to read and understand in about an hour or two, were replaced by Systemd, which may take days just to read source. Not sure I understand why you would cry about that, systemd is actually not a very complex project if you're used to low level C daemons. The most complicated part is the d-bus portions, but those are mostly a lot of boilerplate, and you should be understanding it anyway if you use a modern system with d-bus. Trivial initd and trivial shell scripts are also lacking in quite a bit of functionality compared to systemd, at least in my experience those would tend to grow until they became brittle and unmaintanable.