Yup. I work for a company (in the USA) where I currently have 30 PTO days a year, plus a week of dedicate wellness days, plus corporate holidays (we get a decent amount of those). I very regularly take1 day a week off every week of summer (think about it, that's only 12-15 PTO days and still gives alot to use the rest of the year). I love that I get to spend an extra day with my family not working during the summer.

I interviewed at a position at a company with "unlimited time off" and I asked them if that would be an acceptable use of the unlimited time off policy, and I got alot of hemming and hawing and finally got an answer of "No one has ever asked that and you'd have to discuss this with your manager and team". The manager said, well that's not really how unlimited time off works. It means that you simply get to leave and do things that you need to do (dr appt, pick up kids early from school, etc etc) and then be able to take a week or two of vacation on the beach without working. That's not unlimited. That's "as needed", with "as needed" NOT defined by the employee.

The job was interesting, but not interesting enough and I really value my current position so I walked away.

"But if you were using a DEVICE that had a voice search feature, and the DEVICE search feature could return results from multiple apps -- and in fact this is one of its competitive advantages so you don't have search for a movie or song in 4 apps... what would you expect then?"

This is the part where I said that I can see some argument for it. So I do mostly agree with what you're saying here, but I think it boils down to how roku presents the voice search capability. If it's clearly an external search, that's one thing, but if, from a UX perspective, appears to the user to be an in-app context search, it should be unexpected that it doesn't return youtubetv results. I haven't used a roku in almost a decade so I have no idea what this looks like :) But, based on the context of how it works, I think that's really relevant. And I do not trust Roku to present the proper side of the story. Even if i twas a "global" applcation, I would still see a case made that if it is triggered from inside the app itself, google's stance is valid.

According to the article #3 was already done in the past, and I do agree, that if that's what Google did back then, that's not really fair. However the limited googling I spent on this doesn't find anything about that dispute. I mean if Roku hand-selected certain apps to display results from, but explicitly excluded others (i.e. preferential treatment based on whatever terms Roku decides) then I don't think an unreasonable contract negotiation stance from Google would be, well you need to display result from ours too if you expect to have our service on your device.

https://www.protocol.com/youtu...

That doesn't feel so draconian. The search results thing, I can see some argument for, but at the same time, if I were using an app that had a search feature, I absolutely would expect it's search results to be in app results.

And the AV1 codec thing. I absolutely call bullshit on Roku.

Those are the things Roku is claiming Google is requiring. Until the terms are publicly disclosed by someone other than Roku or Google, I'll take that with a grain of salt.

why do you assuem you're beta testing a package that is released on centos stream 8 before it's on rhel 8.. the rpm has already been tested, verified and ready to go. do you think it gets any more additional testing before it's released on a rhel8.x point release?

Because in most cases it does not . If you are beta testing the apckage on centos 8 stream, then by that same logic youa re currently beta testing rhel 8.3 packages when they are released.

CentOS has support? :)
I mean it's a completely free as in beer and free as in speech product. What support do you expect. I'm being a little tongue-in-cheek here.

While I totally understand why those with an enterprise bent are upset, let's look at this a little closely. Centos Stream will have branches for each release. Centos Stream 8 is going to be around as long as RHEL8 is. So the "LTS" nature of centos does not go away.

So what changed? Right now, if I run a centos 8 server, I get critical and security package updates as they roll out and are available. The rest of the package updates are synced to a point release. CentOS 8.3 came out recently and I had 630 packages updated on my `dnf update` run. Were those package releases untested and un-QA'ed until CEntOS 8.3 was released? No, there is a process for QA and testing each package update (or bundle of package updates if they are related). They were tested, and verified long before centos 8.3 was released. They weren't deemed beta, or unstable, but they were not critical or security fixes, so they are not pushed to the repos until the point release is released. CentOS stream will instead, push these packages to the released repos when they are tested and qualified. It's not going to wait for a minor release of CEntOS to roll them up in. That's it. That's the MAIN change. These packaes aren't going to be beta, or untested packages - to be fair, some packages are automatically promoted based on karma but that's the case the minor release roll up process as well.

So, let's be clear here, the *STABILITY* people are looking for is not package stability. They want a static, unchanged operating system for as long as possible.

I call this the "enterprise IT" model and I understand why it exists, I understand that IT resources are being pulled back and limited all over the world because corporate policy makesrs have their heads up their asses.

I understand that this is painful for some, but I believe the conservative slow moving nature of "enterprise IT" is a huge problem that needs to be relooked at. Sadly, this won't do that. This will push people to a different distro.

There is one other bright side to this. Right now, under most conditions, centos lags rhel releases. It always has. Centos 8.3 was released a little over a month after RHEL 8.3 was released. Having centos stream 8 being the upstream of rhel 8, means taht centos stream 8 will get the package updates before rhel 8.3 will. In a dev/test/stage/prod release cycle, this allows one to use centos 8 in the earlier stages to confirm changes and adjust to them BEFORE rhel 8.3 is released, and taht critical customer upgraded on day one and found an ABI compatibility problem with your product :) So there is a potential silver lining.

but... "On Sunday, the HKSP submission sparked interest in the Linux community as could signal Huawei's wish to possibly contribute to the official kernel. Due to this, the patch came under immediate scrutiny, including from the developers of Grsecurity, a project that provides its own set of security-hardening patches for the Linux kernel."

Really? Shouldn't this level of scrutiny apply to ANY security change. I mean all sources should be considered as potentialy having an ulterior motive.

I get that the google play store security is more lax than iOS. But it's still more than a "random" installer by software developers who (even good ones) make really huge security mistakes. They didn't bitch about Apple's same policies around iOS because they didn't have a choice. Google's policies give you a choice but also makes it pretty clear the risks of going outside the store. And given the initial security bug crap discovered in the epic installer - uhh seems well deserved :)

If google had simply not given them a choice, they'd have no whining to do :) So I guess there is that. Or maybe they can release a Fortnite OS and get that to hardware manufacturers and through cellular carrier approval policy. I'm sure that'd cost them less money :)

I understand the importance of knowing this from an epidemiology perspective but given that most of the websites peddling the "Chinese lab origin theory" also seem to want to point blame that this is an engineered virus or somehow china's fault, how is this not fearmongering? If we assume that the lab is "just happened to be studying coronaviruses" and that "labs study wild viruses", then the virus isn't "lab origin" is it? It's a wild virus that someone happened to be studying. If it happened to "escape" from that lab, it's important from an epidemilogy perspective, but the virus still existed in the wild and likely existed before. The "chinese lab origin" theory is doing nothing more than piling onto the "this is a chinese virus" bullshit, which is no longer important given that it's fucking everywhere.

Red hat doesn't directly support any recent version of docker. They've had a forked (atomic) version of the docker engine for as long as I recall. If you install docker-ce or docker-ee the support for that game from docker (community or from the company for EE).

The recent change in fedora didn't stop supporting docker. They made cgroupsv2 the default which docker doesn't support. They document how to enable cgroupsv1 and how to install the moby-engine (open source upstream for the docker project) and technically that's still "supported" depending on how you want to define supported with open source.

One could turn this around and say what the hell is taking docker so long to support cgroupsv2. Speaking of which, when this happened in fedora there was a pretty massive flurry of activity on cgroupsv2 support for docker. Probably not a coincidence :)

Disclaimer: I use docker every day for my job and as an integral part of my dev environment and I also use Fedora as my daily driver and I've switched to podman and so far it's been decent. Some growing pains but nothing horrible.

Clearly you don't have a family. It's not that mystifying. It's extremely hard, without draconian measures that greatly impact usability to prevent family from sharing a shared services. Also, if netflix/disney/hulu/whatever were to expect every family member to pay for an account that would get out of hand fast - and that would absolutely encourage piracy. If they blocked you based on IP address or block - that would be more like the old school cable tv model, but that's the whole point of streaming is you don't have to be at home to watch.

The key here is, they are NOT selling you "a service that only one person can use at a time". They are trying to account for mobility and family convenience. It just happens that flexible functionality can also be used for other purposes - like password sharing.

Paywalled so I can't read the article but I have an RRD graph that, at least based on the summary, shows they're full of shit.

Although I suppose the fact that I have an RRD graph makes me not "most people" :)

That is a good question but if you look at this:
https://www.wirelesspowerconso...

There are surprisingly few phones that are certified for > 5w Qi charging. I'm guessing there's gotta be a reason for that.

To be fair, there's a pretty big difference here.
1) qualcomm's quick charge actually violated the USB spec. Their quick charge still used USB cables to provide power. micro-usb wasn't designed to handshake or negotiate the cable's capabilities to the charger and the phone. The usb cable standard did NOT allow for quickcharge power draw. That actually IS dangerous.
2) Google's 10w proprietary standard is negotiated, and there's no intermediate medium (unless you count the air molecules between the charger and the device, and I'm pretty sure there's no specification defining their behavior)

By no standard definition is usb-pd proprietary. It's no more proprietary than USB is (so if you consider USB proprietary, well fine, here's some more tin foil).