Just last week, we received notification that IBM is rolling out a "program" to upper-level employees with decades of experience. The idea is that we would work reduced hours for the next year at full pay, and then leave IBM after a year (next March, I believe.)

Of course, this is for US employees only. I think we can be sure that the replacements for these employees (if there are any) won't be in the US.

You didn't "cut cable" if you didn't have it in the first place; the number they're citing is a percentage of total households without cable, not the number of total households that had cable and got rid of it.

It was "proven false" by mathematicians who considered the number 200,000 to be the same as "infinite."

A quick Google shows that our resident village idiot's claim is nonsense; tuition was charged in the 1950s, although it was (even adjusting for inflation) much cheaper than it is today.

Sure there is; the search engines can ignore robots.txt for reddit.

It's one thing to use robots.txt to say that you don't want the content on your website indexed by search engines, but if reddit is pulling this kind of stunt (giving that access only to Google,) then there's no ethical problem with other web search engines bypassing whatever anti-scraping techniques that reddit uses.

Whenever I've had to return something that was obviously a prior return, I always take a sharpie and write "BROKEN" or something similar, in big letters, on the packaging. I figure that should keep them from trying to just send it out again.

run0 doesn't implement a configuration language of its own btw (i.e. no equivalent of /etc/sudoers). Instead, it just uses polkit for that, i.e. how we these days usually let unpriv local clients be authorized by priv servers.

Polkit .rules files are quite readable, for the most part, but they're also written in ECMA-262 edition 5 JavaScript! I'm not really thrilled with config files that are executable and might have odd exploitable language features I don't really need. But, whatever you do, don't run it with an argc == 0 .

This means production workloads can rely on the Rekor public instance, which has a 24/7 oncall rotation supporting it and offers a 99.5% availability SLO for the following API endpoints

(Rekor README)

And that is the key reason to stay far, far away: this system is yet another identity service which happens to be supported by software. Like most identity services, they have carefully constructed it to ensure that the user receives no actual proof of identity. That proof resides on a ledger in some cloud server, somewhere, and verifying anything requires queries against the service. This means that the service can:

• Start charging for "blue checkmarks" or for the ability to put entries in the ledger
• Start charging for verification queries
• Decide they don't like you today, then lock you out of either of the above
• Decide what Certification Level you or your organization have today
• Learn how often you commit/push/release, potentially monetizing this data stream
• Learn all the software (or other blobs) you verify at once, giving them insight into your software stack
• Stop existing at any time, leaving its users without anything of value

I don't see the words "distributed" or "federated" anywhere on the tin, with the possible exception of OIDC. But they are in control of what third-party OIDC providers they trust, if any. If their ledgers are not fully distributed, they are only as good as the metal in their hard drives. (And are one ransomware attack away from ruin and oblivion.)

Despite its obvious flaws and shortcomings, the whole point of the GPG Web of Trust is to escape the tyranny of these centralized ID providers. The cost is having to keep something secret—i.e., the key. cosign frees you from this requirement, but you are forever chained to their service. For me, this is not worth the price of admission.

One open problem in source or binary validation is trusted infrastructure—or the lack thereof. Projects that wish to use cloud computing for their builds, and to guarantee that the binary builds come from said cloud, usually have no choice but to trust The Cloud with their precious $identity key. This can leave it exposed to bad actors. The solution to this problem is reproducible builds. If your artifacts can be reproduced, they can be signed on non-cloud hardware that your project maintainers can see, touch, and trust. The solution is not "add yet more cloud servers with yet more keys run by yet another organization, making our system even more fragile and complicated."

But there's usually not a lot of money to be made in making things simpler.

I can just imagine a system where you get a "one minute charging speed boost!" when you choose to watch a video ad...

I absolutely do. I climb inside of it, and it takes me to a place where there are canned diced tomatoes.

That's not what the person you replied to was talking about.

Apple will not allow an app to be hosted in their store if the service charges a higher price using payments through the app than it does using other methods.

It's funny, I keep hearing people say that, which was the exact opposite of my experience. I had a Discover card for six months last year, and in that time had more problems with their customer service than I have had, in total, in twenty-five years or so with other credit card companies.

Never had any experience with Capital One for a credit card, but all I can say is good riddance if they kill off Discover.

"A human" can't review them all in-depth. However, the most profitable company in the country can afford to hire multiple humans, who could review all of them.

I was responding to the claim that "Not even the biggest sites in the industry could afford an editorial team capable of playing 50 games a day to find and write about those worth highlighting." Exactly what "write about" means isn't defined, but as I've demonstrated it is certainly possible to do better than "one-word games". With their numbers, after you've weeded out the trash, you're left with 2 games per day. It should certainly be possible for a competent team to play that many games for a few hours and write a short review.

If you had to play for a significant time to discover that it's "worthless," then the game isn't "absolute dross," so it doesn't matter for the purposes of their argument.

This:

Is completely in opposition to this:

If 48 of the games are "absolute dross", then a reviewer should be able to identify that fact within, say, ten minutes. Say you've got a staff of five people to review new games; that hardly seems unreasonable for a storefront the size of Steam, so each one would have to review ten games per day. Determining which games of the ten are total crapware should take no more than a couple hours, which leaves you six hours during the working day to give a fair shot to those that have some promise.