121–130 of 236 posts
Earlier quoted context omitted.
And goto being used for error handling is pretty stock standard across most C codebases I’ve worked on or seen over the years, so I’m not sure what the particular gripe is there
Since when is "we do it all the time" the same as "it's a good thing"?
Well written code is the best code. Some well written code uses goto. Some not well written code doesn't use goto
Earlier quoted context omitted.
I don't understand people who want to remove choice. Don't want the ability to install apps from untrustworthy sources? Don't enable the option that gives you that ability.
The position is self-defeating. How can you hold it and at the same time advocate against their choice to use a system that doesn't have the ability to install apps from untrustworthy sources? The availability of such systems is obviously an increase in available choice, not a decrease.
int fd, epfd;
struct epoll_event event = { .events = EPOLLIN };
fd = open("/dev/binder0", O_RDONLY);
epfd = epoll_create(1000);
epoll_ctl(epfd, EPOLL_CTL_ADD, fd, &event);
ioctl(fd, BINDER_THREAD_EXIT, NULL);Earlier quoted context omitted.
I don't know the reasons behind that policy, but I'd guess with the exploit already being used, there is less incentive to keep silent about the issue. The opposite is true: putting more pressure on the vendors to provide patches, and disclosing any malicious actions that are already underway as soon as possible
They could tell vendors about the issue earlier without telling the rest of the world earlier though, can't they?
To me, the biggest part of this story is: 1. Over two years ago, this was apparently detected automatically by the syzkaller kernel fuzzer, and automatically reported on its public mailing list. [1] 2. Over a year and a half ago, it was apparently fixed in the upstream kernel. [2] 3. It was apparently never merged back to various "stable" kernels, leading to the recent CVE. [3] So you might read that and think "Ok, p…
The Linux kernel is a glaring example software malfunction due to its combination of moderate defect density and incredible extent, along with a culture intolerant of competence. People who became subsystem maintainers because they happened to be hanging around a mailing list in the 90s are still gatekeepers of important subsystems despite their now-decades-long records of continuous malfeasance. Patches that demonst…
I hate that people keep peddling this nonsense because they wrote a little C and read a headline about “goto considered harmful”, which is a gross oversimplification and a BAD piece of “wisdom” that for some reason won’t die. This is how serious handling in C is done. Please stop repeating this tired trope.
Earlier quoted context omitted.
And goto being used for error handling is pretty stock standard across most C codebases I’ve worked on or seen over the years, so I’m not sure what the particular gripe is there
Since when is "we do it all the time" the same as "it's a good thing"?
Different ballgame from the subject of Dijkstra's manifesto.
Earlier quoted context omitted.
>extremely inconvenient. Maybe. I'd argue "extremely". It does suck, for instance, that Discord as a Flatpak can only access a fixed subset of $HOME directories. But it can't scan your machine's processes like ordinary Discord can (to report the game you're playing), which is a privacy gain. The security (and portability) advantages of sandboxing/containerizing apps may outweigh the hassle of the workarounds/memory i…
There'd be a case for sandboxing proprietary software, for sure.
So maybe, instead of trying to somehow make it safe to run untrusted software on our machines, we should focus on making sure all the code that runs on our machines is trusted - not in the sense of "proved correct", but in the sense of "written without malicious intent". If you regard Discord scanning your processes as an unacceptable invasion of privacy, and it bothers you that there's no way to turn that off, perhaps avoiding Discord is a better solution than trying to sandbox it.
Earlier quoted context omitted.
I don't understand people who want to remove choice. Don't want the ability to install apps from untrustworthy sources? Don't enable the option that gives you that ability.
The position is self-defeating. How can you hold it and at the same time advocate against their choice to use a system that doesn't have the ability to install apps from untrustworthy sources? The availability of such systems is obviously an increase in available choice, not a decrease.
Saying "doesn't have the ability to install apps from other sources" is the same as saying "doesn't give you the choice to install apps from other sources" -- it's removing a choice.
If you don't want to install apps that aren't approved by Apple then... don't. You could choose not to even if your ability to choose was not restricted.
This is another great chance to root your phone and take complete control of what you should rightly own.
In Android land you can buy a phone where the bootloader can be unlocked and directly flash a pre-rooted ROM rather than relying on people exploiting security vulnerabilities like this.
“It’s advisable that you don’t install apps from non-trustworthy sources, ” Unpopular opinion but this is why I prefer walled garden apple for my family then alternative.