r00ty

If they cannot see a verified human gaze they won’t let you even load the site!

Yes, the tech exists already on phones. Not sure how they’d enforce it on pc.

“Sorry, YouTube is not available to systems without a functioning camera.”? Perhaps with a link to premium :p

When these tools hit their bottom line enough, they will go the extra mile to block them.

The only thing stopping them doing this right now, is that they know it would get regulatory pushback. It has a real chance of causing laws to be made about when and how advertising is appropriate, and those laws might stop some of the things they’re doing now. So they sit as close to that line as they can without crossing it so they can keep self-regulation.

The moment they believe world governments wouldn’t stop them doing it, is the moment they’ll do it.

And in terms of benefit for the advertisers and service providers, it’s a no-brainer. Advertisers know that a large percentage of people tune out, or even leave the room when an advert is on. I think it’s part of the reason they kept them so short on youtube, because if they showed you that there’s 1:30 ad break you might go to the toilet, get a drink, or anything else that takes you away from the ad. If they show you 15seconds, well you’ll probably just sit that one out.

An advert they know people are actually watching is worth a LOT more to advertisers.

I started playing with rust last week (just converting a couple of C# projects so far), and I’m going to say that once you understand that mutexes/rwlocks are wrappers around the actual data, it (to me at least) feels better.

Don’t get me wrong, it’s an absolute headache for anyone that’s acquired intermediate or better skill in one of the Cx languages. The paradigm shift is still hitting me hard. But this was one of the differences I actually think is an improvement in probably most use cases.

You realize there’s 8 billion people on the planet? The majority of people either didn’t (or luckily for them still don’t) know who this guy is.

I don’t think users should reward the behaviour. If they actually lost money because of these decisions, they would stop making those decisions.

But, we both know enough people will bend over and take it.

But, in terms of cost it can be a good move. It’s just for us, it makes at best, no difference.

Pretty much how it always works with business.

Well, I would say it SHOULD bring overall prices down. If the cost to build the top of the line model comes down to say the same as the mid-range model AND more people are say buying up. It means that competition would push overall prices down.

But of course not, it benefits the companies most, and given the choice of lower prices or more profit, they’ll choose the profit every time.

If they go subscription only (because recurring revenue is the current business buzzword, so of course they will go subscription only) then overall cost for the life of the car will definitely be higher yet “feel” more affordable.

You can check to see if you can enable hardware transcoding. I find the delay is usually transcoding building up a buffer and if you have a good GPU/APU in your server it’s often a lot quicker.

Pretty sure on jellyfin by default that is off. Mainly because you need to install some packages to get the devices available under linux usually.

Now, I can “kinda” see the rationale behind optional features on a car being either enabled via software or subscription. I believe the permanent enable price should be the same as if you added the hardware to the car as an option.

As to why this might make sense for a carmaker. In my work I’ve visited car manufacturers before, and from what I could see it’s quite expensive and adds time to support the various options when building a car. You see they have the main production line, and units are pulled off the main line to fit the options at various points and then reinserted and this causes problems for efficiency and price per unit I think.

So, there’s probably a cost saving to making the base car have all the options fitted and having a completely standardized production line. However, the expense is likely going to mean if they sold the base car at the usual base car price they would either lose money, or at the very least, the profit margin wouldn’t be worthwhile.

However, if you know a certain percentage of people will want the options, and you can enable it with software later, it’s possible building the hardware into every car as standard would work out overall cheaper. They might also be able to upsell to more people by making a subscription option, perhaps with maybe a free trial for the first say 3 months of ownership. That is, they turn everything on for 6 months for free, then revert you to the package you paid for. Hoping that you liked some of the features and will pay or subscribe to keep them.

What I don’t like is when this stuff might become ONLY available as a subscription, the overall move toward subscription models for everything irks me a lot. I’d much prefer we still get to choose a package, and have the ability to upgrade later.

So I think my point is, the argument “the hardware is there anyway” doesn’t really work, because they are likely going to install the hardware at a loss, on the assumption (backed up by their own numbers) they will sell enough to make a bigger profit overall.

They also likely bake into the numbers that a very small number of people will hack the car and enable the features anyway. The vast majority will not do this, though.

Yes, and no. A firewall is still a firewall if it is configured to have all ports open. The Linux kernel firewall is still active, even though its default configuration is, everything open.

My point is, for some reason there are some that are not configured to block incoming IPv6 by default. When that should be the standard home/consumer router default setting. Then the user can open ports to ips as they need them.

You can, and there’s a specific flag to set on nd/ra to tell the client to get other information from djcpv6. But so far I’ve not made it work and also, it likely won’t work on android.

Really the way forward is for routers and devices to implement the same options as exist on dhcp. But, time will tell how that gets on.

This is a weakness of ipv6 but it’s really the lack of widespread implementation that’s behind this. If we were all using it, there would be more onus to get this stuff working.

I think it depends on all the caveats I mentioned. If it could have worked with an outgoing connection, then someone with a bad client could execute it for sure. The VPN wouldn’t protect you.

Dhcpv6-pd is used by isps for prefix delegation, which most routers support now (not so when my isp first started with it).

But for advertising prefixes on a lan most networks use router adverts.

They’re different use cases though.

You can include some information in router advertisements, likely there will be rfcs for more. Not sure of the full list of stuff you can advertise.

For sure I’m quite sure I had dns servers configured this way. I’ll check when not on a phone to see what options there are.

Best thing to do to test the firewall is run some kind of server and try to connect to your ipv6 on that port.

Like I’ve said in other posts, routers really should block incoming connections by default. But it’s not always the case that they do.

That’s true. But there are not many differences. It’s just, the differences there are, are crucial to understanding it.

Yep, it’s all good. In my opinion, IPv6 routers should just be dropping incoming connections by default. If you want to run services you give your machine a static IPv6 and open ports on that IP/port specifically. It’s actually easier than NAT because you don’t need to translate ports and each IP can use the same ports (multiple web servers on 80/443).

I do agree that the average joe is going to expect NAT level security by default and that would provide that.

It’s really not though. ISPs are a problem, but every hosting provider I’ve used has offered IPv6. It’s really trivial to setup IPv6 name DNS, and host a website on both IPv4 and IPv6. I just do it by default now.

Once it becomes the default to deploy to both, if IPv4 died then the IPv6 side would just keep working.

For DNS, you can make a single glue record contain an IPv4 and IPv6 address.
DNS just needs A and AAAA records for the Name servers. NS records still point to the hostname as normal.

For Web servers, the web server just needs to bind to the IPv6 address(es). Then in DNS just have an A and AAAA record for each website hostname. The server name directives will cover both.

There really isn’t much to it right now. The technology is mature now. It used to be a pain, but now it isn’t.