Patents published in 2022 showed Valve are definitely working on an untethered VR headset, new VR controllers, and a Steam Controller 2. Rumours are they went into mass production in Nov 2024 so we could be near an announcement in the next few months. Typical Valve style, however, is to announce it out of the blue.

But given the success of the Steam Deck, and the money they’ve funnelled into Arch Linux support for ARM processors, I’m pretty confident these aren’t just rumours.

Don’t worry, Valve will be blowing up shit next year.

They might be wanting to build a proper desktop with RGB and all the jazz. While the Steam Deck does kick ass when plugged into a keyboard, mouse, and monitor, it’s not quite as impactful as a tower in terms of presence.

I use my Deck with the official dock all the time so I don’t disagree with Dindonmasker’s point that the value of a Deck is tremendous and a great alternative to building a tower.

Honestly, it’s very likely just Salesforce since that cantankerous, janky beast is so easy to use poorly.

CRM is “customer relationship management” i.e. a system to manage interactions with customers such as tracking calls, marketing emails and collateral, meetings, quoting, support tickets, and more. It tracks the lifecycle/pipeline of a sale from prospecting, lead qualification and solution mapping, demos and meetings, proposals, negotiations and commitment, opportunity win/loss, license generation, onboarding, renewals, and a ridiculously huge number of other things.

It’s not just tracking the numbers but giving you a centralised system that all other business operations can hook into so you’ve a single source of truth about customer state so that various other operations can be triggered.

When you’ve hundreds of sales people, numerous systems, marketing people, support teams, and more all reading and writing to the same CRM system, if that “system” was a spreadsheet, you’d be constantly deadlocking and race conditioning the hell out of it, not to mention how absurdly huge that file would become with all that historical data (since a big part of CRM is also projections and other analyses across all the data you have).

And Ubuntu, no? Wasn’t that the big selling point of Ubuntu back in the day?

Good bot

Reference for the admission?

And it’s made by a Bitwarden developer.

They highlighted it was a bug and said it would be fixed very soon after it was flagged. It was addressed in a matter of days. You can build the server with the /p:DefineConstants=“OSS” flag still and you can build the clients with the bitwarden_license folder deleted again (now they’ve fixed it).

I don’t understand why you’re throwing FUD about this. Building without the Bitwarden Licensed code has been possible for years and those components under that license have been enterprise focused (such as SSO). The client is still GPL and the server is still AGPL.

This has been the way for years.

Cool. They got that sorted nice and quickly.

Edit:

I don’t get why people think they’re suddenly doing stuff under a different license to subvert the open nature of the project. They’ve been totally transparent on what isn’t part of the GPL/AGPL licensed code for years.

SSO, the password health service, organisation auth requests, member access report blah blah have been enterprise features under the Bitwarden License for ages and they architected the projects in a clear and transparent way to build without those features since they added them.

Thank you for the smug response however I did indeed read the article and going from 13 months to 10 days is not a trend but a complete rearchitecture of how certificates are managed.

You have no idea how many orgs have to do this manually as their systems won’t enable it to be automated. Following a KBA once a year is fine for most (yet they still forget and websites break for a few days; this literally happened to NVD of all things a few weeks ago).

This change is a 36x increase in effort with no consideration for those who can’t renew and apply certs programmatically / through automation.

Smells like Apple knows something but can’t say anything. What reason would they want lifespans cut so short other than they know of an attack vector that means more than 10 days isn’t safe?

AFAIK they’re not a CA that sells certs so this can’t be some money making scheme. And they’ll be very aware how unpopular 10 day lifespans would be to services that suck and require manual download and upload every time you renew.

You okay?

You’re not wrong. Research into models trained on racially balanced datasets has shown better recognition performance among with reduced biases. This was in limited and GAN generated faces so it still needs to be recreated with real-world data but it shows promise that balancing training data should reduce bias.

Let me guess, UltraAV whitelabels Kaspersky…

I’m not insisting anything; stating C is not a memory-safe language isn’t a subjective opinion.

Note I’m not even a Rust fan; I still prefer C because it’s what I know. But the kernel isn’t written by a bunch of Lewis Hamiltons; so many patches are from one-time contributors and the kernel continues to get inundated with memory safety bugs that no amount of infrastructure, testing, code review, etc is catching. Linux is written by monkeys with a few Hamiltons doing their best to review everything before merging.

Linus has talked about this repeatedly over the past few years at numerous conferences and there’s a reason he’s integrating Rust drivers and subsystems (and not asking them to fork as you are suggesting) to stop the kernel stagnating and to begin to address the issues like one-off patches that aren’t maintained by their original author and to start squashing the volume of memory corruption bugs that are causing 2/3rds of the kernel’s vulnerabilities.

No idea what you’re being downvoted. Just take a look at all the critical CVSS scored vulnerabilities in the Linux kernel over the past decade. They’re all overwhelmingly due to pitfalls of the C language - they’re rarely architectural issues but instead because some extra fluff wasn’t added to double check the size of an int or a struct etc resulting in memory corruption. Use after frees, out of bounds reads, etc.

These are pretty much wiped out entirely by Rust and caught at compile time (or at runtime with a panic).

The cognitive load of writing safe C, and the volume of extra code it requires, is the problem of C.

You can write safe C, if you know what you’re doing (but as shown by the volume of vulns, even the world’s best C programmers still make slip ups).

Rust forces safe® code without any of the cognitive load of C and without having to go out of your way to learn it and religiously implement it.

This slogan was from the 90s (1993/94 maybe?).

deleted by creator