creshal

Model quality is only one aspect, the bigger problem is making it work in a fully integrated enterprise platform, and Google has always been lacking when it came to the latter.

At this rate, if Google has a flagship model, you're better off plugging it into a competitor's tooling than hope Google figures out how to use it.

The primary advantage of dedicated hardware accelerators for the past ~15 years been power efficiency, rather than performance. Not much of a problem on a desktop, but very noticeable on mobile devices.

kubevirt is a cute joke, but hardly a replacement for ovirt or vmware. It's a real shame redhat keeps sabotaging itself to chase hypes with half-assed non-solutions.

"around" is the best way to describe it; the libvirt/virt-manager ecosystem isn't dead, but redhat killing off ovirt/rhev support drained a lot of resources out of it.

And for some bizarre reason people decided that the much less mature (both organizationally and technologically) proxmox VE is the best thing since sliced bread, so everyone who does care about linux virtualization is now trying to hammer some homelabbers' collection of perl scripts into a replacement.

It would be funny if it wasn't so sad.

as long as the people doing the work are recognized and compensated.

Are the 15% getting 80% of the compensation, though?

I'm baffled by just how much Google continues to screw up their AI overview. Even duckduckgo manages to provide significantly better results.

Step one: Decision makers who can change these processes need to be aware of this problem. Many companies fail this simple task.

Step two: These decision makers must be held accountable for the success of the process. Many companies fail this simple task.

Step three: These decision makers must be willing to admit that they made a mistake, and risk loss of prestige and political capital. Guess how likely that is.

And the bigger the company, the worse it gets. It's a good thing we didn't go through 20 years of consolidations and mergers. Oh wait.

Yeah, Elon's whole shtick is make things scale up that everyone else thinks can't scale up. Sometimes it works (batteries), sometimes it works spectacularly well (Falcon 9), sometimes it fizzles out because it turns out everyone else was right (tunnel boring, solar tiles).

Jokes aside, I don't really see the appeal of a demake of helix; it only really makes sense to me as "vim but far more concepts integrated as first-class features rather than addons"; take that away and you have vi with less muscle memory. So, kakuone with the serial numbers filed off.

~90% of the failure modes grub can fix don't exist without grub. I can't remember any time when its needless complexity was actually a net benefit compared to literally any of its alternatives (and between gummiboot/syslinux/efilinux/isolinux/systemd-boot/efistub I've used a lot of them).

Grub is really impressive in how it consistently spent the last 30 years focused on improving everything except the UX of the one workflow 99.99% of its involuntary users need it for (boot linux as reliably as possible, and make it easy to debug when it does not).

Or use UKI and throw the current kernel to /efi/boot/bootx64.efi; there's plenty of solutions to sane bootloader/kernel management if you're willing to invest 15 minutes into the topic and not act like it's scary and complicated (it really is the opposite).

If your definition of refinement is "looks like a Macbook", sure. Personally, if I wanted a laptop that looks like a Macbook, I'd buy a Macbook.

Oh look, another generic Macbook clone.

The point was usually not usability. It was identity.

And we're not even getting usability out of it! Each of those bland react-angles is subtly inconsistent with the OS, with each other, and very often, itself. And in 6 months everything will move around again, for no reason other than to keep the responsible managers employed, without improving UX. And a11y is crying in a corner somewhere, forgotten.

Don't be silly, this is the JS ecosystem. Why use your brain for a minute and come up with a 50 byte helper function, if you can instead import a library with 3912726 dependencies and let the compiler spend 90 seconds on every build to tree shake 3912723 out again and give you a highly optimized bundle that's only 3 megabytes small?

Scammers have no problem waiting 24 hours, so this doesn't protect incompetent people at all.

To be blunt: I don't care. Don't make their incompetence my problem.

But putting my design hat on here: couldn't this be the whole approach?

No, because protecting users is just an excuse. The overreach is the goal.

That includes school-issued Macs, so I don't see how that's an argument against Chromebooks.

Yeah, you'd find out about it all in the newspapers a few hours later, and none if it was "clap to yourself in an empty room" impressive anyway. I was around back then and I didn't feel the need to act like a drug addict whenever Steve Jobs opened his mouth.

And faking being sick so he could clap at Apple marketing events. He kinda lost me there.

OTOH, client Windows is the smallest and least important building block in it. Microsoft is helpfully also setting all their native apps on fire too and replacing them with webslop that runs equally poorly on MacOS, ChromeOS and Linux as it does on Windows 11, so the biggest concern is (A)AD integration and centralized management… and all three are decently manageable these days. If Microsoft didn't throw in the Windows licenses for free, more orgs would already be looking at ditching Windows 11, and if it keeps getting worse, even that won't look like a good deal any more.

Maybe what bothers you is that you have a branch for tags, yeah, that's an extra level of indirection, but this lets you separate between user facing information in the master branch commits and developer facing information in the release branches commits.

That's such a marginal niche use case to build your entire organization around… why would you make this the default approach?

The standard is, for better or worse, gettext; it's good enough that any attempt to replace it runs into the problem that people can't agree on how much better an alternative needs to be to be worth migrating to; so you get a constant churn that so far hasn't seen any clear winner.

Depends on a lot of factors. LEO has high drag, but good radiation shielding, so if you've got a low enough orbit you can use most embedded hardware but need to compensate with bigger thrusters and bigger fuel tanks if you want it to survive "any length of time" without burning up from atmospheric drag.

apt-mark manual has allowed the same functionality in apt since forever and probably inspired apk's copy of it :)

They're unsure because a lot depends on the legal status of children born to non-citizen parents in the US after a executive order tried to revoke birthright citizenship: https://www.bmj.com/content/390/bmj.r1538

If that EO was legal, then sharing the data is, too. If it wasn't, then it's probably a privacy violation, but the CMS isn't allowed to make that call themselves, they have to rely on court decisions for it. And challenging EOs is not trivial.

Since they're operating in Europe it's trivial to split manufacturing into 3+ places that are within an hour drive but also in 3+ distinct jurisdictions that are part of the same free trade zone, so no tax authority can have a full picture either. And you'll never get, say, French and German tax authorities to voluntarily talk to each other.

No, it's a generic android keyboard and works with all apps. But you need a keyboard like it (arrow keys, ctrl, etc.) for termux to not be a total PITA to use.

(Android has full physical keyboard support, so with it you can use Ctrl+A/Ctrl+X/Ctrl+V in all input fields. Usually a lot faster than fumbling with the touch equivalents that keep randomly bugging out…)