Yeah, so many places ask for phone number that don't really need it that I assume the phone number is a unique identifier used to combine individual's data across websites.
Most of the time I use a made-up 555 number or if it needs to send an SMS to verify, I'll use a free SMS numbers.
Mostly only because Tesla doesn't share this data outside of Tesla, unless they leak it to news outlets to make it look like the accident was all your fault and not Tesla's.
Tesla tends to only leak that stuff when they look bad. It's not like they are necessarily outright lying, they are just telling their version of the truth....
VRR is Variable refresh rates, so if there is nothing going on in the content, they can bring the refresh rate down and save processing, thermal issues and energy. If there is a lot going on(say a game), they can ramp the refresh rate back up super high.
There are a few different "standards" around VRR, not every device supports all of them.
Their explanation of the reason for VRR is bad. The primary reason people want it is gaming where the game is not locked to a specific frame rate. Without VRR, the timing of a frame being delivered isn't necessarily going to match when the display is expecting a new frame. This leads to one of two effects. Either the display is forced to hold an old frame for longer and pick up the new frame on the next refresh cycle, which creates stutter. Or the display switches which frame its using partway through the refresh cycle, which creates a visual tear in the image.
I don't understand this thinking. The GPL is more restrictive than the FreeBSD license. You have more freedoms with the FreeBSD license than you do with the GPL(of any version).
> I wish FreeBSD held the position Linux does in the market today. That would be heaven.
Well The BSD's were embattled with a lawsuit from AT&T at the time Linux came around, so it got a late start as it were, even if it's a lot older.
probably because OpenBSD developers use laptops, so they port the OS to laptops all the time.
FreeBSD has a few laptop developers, but most are doing server work. There is a project currently underway to help get more laptops back into support again: https://github.com/FreeBSDFoundation/proj-laptop
The kernel guarantees that once restricted, that process will stay restricted. The only way for it to un-restrict itself would be to also compromise the Linux kernel. So you have 2 things you have to compromise to own the machine, instead of just 1.
Yes, but basically nobody uses either of those things. Some vendors like Redhat enables some of it by default, but when people have issues getting software to work, the first thing they are told to try is to turn all that stuff off.
Which means in the real world, the likelihood of that stuff being on and secure is fairly low, but not zero.
With landlock, pledge/unveil and similar tech, the developers of the software write and configure it, it's on by default and probably can't be turned off(or at least not easily).
The opposite is true. Containwrization systems were built into operating systems as security features. The whole “Linux packaging is a hellscape of self-induced problems, so let’s duct tape a squashfs onto the side of this new security isolation system and call it a deployment primitive” use case we now call “containers” came later and is a fairly inelegant and wasteful way to avoid needing to solve the packaging hellscape problem. It’s valuable to many! But definitely is the square peg to the round hole (security isolation layer) of setns and chroot and friends.
You can make containers mostly as hardened security wise as a VM (but generally none of that comes by default), the big thing you can't get that a VM gives you is a new kernel instance. In a VM you have to break 2 kernels to totally own a machine.
In a container, provided the container software doesn't do it for you(which is likely true), you just have to break 1 kernel.
OH I think I finally understand your comment... I think you are confusing FreeBSD jails/Solaris Zones with containers. They are not the same things. Containers for instance exist on FreeBSD now, as a totally different thing than FreeBSD Jails.
Jails/Zones are definitely security features. That's not the case for Containers(popularized via Docker).
The technologies that enabled containerization (namespaces, chroot, and cgroups, and their predecessors on BSD/Solaris) were created specifically for security and resource isolation.
The people who came up with "containers" as we know them today found a clever hack: combining those security-oriented tools with a filesystem-in-a-box and packaging system allowed people to package entire OS userlands and run them pretty deterministically in multiple places. The security isolation properties of namespaces/cgroups/chroot also happened to provide increased determinism.
And I'm not criticizing that; containers are a very clever hack that solved a problem a lot of people have. I use them every day.
That said, the fact that containers became so ubiquitous in the first place speaks a completely self-induced problem that we didn't need to have in the software engineering community. That problem is, unfortunately, human/incentive-related in nature, so containers are probably the best we're going to get--problem is, they're not that good.
reply