Mama told me not to come.
She said, that ain’t the way to have fun.
As a manager of sorts, I already know if people are doing their job: the work gets done. I’m involved enough to know how much time their work should take and see through their BS since I do similar work.
Maybe these bosses should do the same: do similar work and you’ll know when they’re BS-ing you.
I loved that controller as a kid.
Why? Look at how many people here say they want Steam OS, and Lemmy skews heavy toward Linux users. This is that, but OOTB.
I don’t think it’ll sell anywhere near as well as the Steam Deck, but it’s also a less exciting form factor. I do think it’ll sell a fair number of units though.
The cheapest equivalent prebuilt I can find with similar specs (RX 7600 is slightly better than the Steam Machine) is $850, and a DIY build is more like $900 (lots of corners cut), so there’s probably not much margin on the prebuilt. Valve is probably saving some cash with their custom CPU, and they’re probably shipping it with a Steam Controller, hence the $800 target. If component prices rise significantly before launch, I could see $1k.
Get ready to riot because there’s no way it’s that cheap. My money is on $800-1000.
That’s a rip off, it’ll be more like 1/4 troy ounce, if that
Eh, I don’t particularly enjoy building PCs, but I do it because it’s cheaper, esp. for upgrades. I’m really not the target market for this.
That said, this is the right product for a lot of people. Many don’t want to mess with their gaming system, they want it to just work. That’s why consoles are popular, and the Steam Machine being a bit more expensive than a console and get access to Steam’s catalog is very attractive to a lot of people, especially if it otherwise works like a console.
I see you ignored my entire comment.
No, I responded to the relevant part. I was using segfault as a metaphor, not arguing that it’s actually the same mechanism underneath. If you’re getting panics in production code, I consider that just as much of an emergency to fix as a segfault, and Rust helpfully gives you stack trace info with it. It’s not the same idea as an exception, which could signify an unrecoverable error or an expected issue that can be recovered from.
I don’t know what is more explicit about expect
It forces you to write a message, so most temporary uses will be unwrap(). I use unwrap() all the time when prototyping for the happy path, and then do proper error handling later. This is especially true in larger projects where I can’t just throw in anyhow or something and actually need to map error types and whatnot. I don’t use expect() much (current hobby project has 4 uses, 3 for startup issues and 1 for hopefully impossible condition) but I think it makes sense when there’s no way to continue.
But yes, unwrap() is perhaps the first thing I look for as a reviewer, which is why it’s so surprising that this is the issue. At the very least, it should have been something like expect("exceeds max file size"). I personally prefer explicit panics in production code, but expect is close enough that it’s personal preference.
Yeah, I’ve been guessing $800-1000. That’s a decent deal on a prebuilt with this performance.
I used Linux for regular desktop stuff before I installed Steam on it. Steam got me back into gaming.
Yes, it’s not the same since you get a stacktrace (if enabled) and a message, but it’s the closest thing you get in safe rust (outside compiler bugs). I compare it to a segfault because it’s almost as unhandleble.
Basically, you don’t want a panic to crash your program in most cases. If you do, make it explicit (i.e. with expect()). unwrap() tells me the value is absolutely there or the dev is lazy, and I always assume the latter unless there’s an explanation (or it’s obvious from context) otherwise.
Nah, if there’s one thing they thoroughly test, it’s the spying.
No, it’s a panic, so it’s more similar to a segfault, but with some amount of unwinding. It can be “caught” but only at a thread boundary.
It is unwrap’s fault. If they did it properly, they would’ve had to explicitly deal with the problem, which could clarify exactly what the problem is. In this case, I’d probably use expect() to add context. Also, when doing anything with strict size requirements, I would also explicitly check the size to make sure it’ll fit, again, for better error reporting.
Proper error reporting could’ve made this a 5-min investigation.
Also, the problem in the first place should’ve been caught with unit tests and a test deploy. Our process here is:
And we’re not a massive software shop, we have a few dozen devs in a company of thousands of people. If I worked at Cloudflare, I’d have more rigorous standards given the global impact of a bug (we have a few hundred users, not billions like Cloudflare).
Ift is precious and beyond compare. It has tools that most other languages lack to prove certain classes of bugs are impossible.
You can still introduce bugs, especially when you use certain features that “standard” linter (clippy) catches by default and no team would silence globally. .unwrap() is very controversial in Rust and should never be used without clear justification in production code. Even in my pet projects, it’s the first thing I clear out once basic functionality is there.
This issue should’ve been caught at three separate stages:
The fact that it made it past all three makes me very concerned about how they do development over there. We’re a much smaller company and we’re not even a software company (software dev is <1% of the total company), and we do this. We don’t even use Rust, we’re a Python shop, yet we have robust static analysis for every change. It’s standard, and any company doing anything more than a small in-house tool used by 3 people should have these standards in place.
It’s Steam Deck verified, no need to check ProtonDB.
Use something like Backblaze or Hetzner storage boxes for off-site backups. There are a number of tools for making this painless, so pick your favorite. If you have the means, I recommend doing a disaster recovery scenario every so often (i.e. disconnect existing drives, reinstall the OS, and load everything from remote backup).
Generally speaking, follow the 3-2-1 rule:
For your situation, this could be:
You could rent a cloud server, but it’ll be a lot more expensive vs just renting storage.
Glad you got it fixed. 🙂
Almost every reply is also explaining what the runtime is.
I boosted it up a bit for other people who come along w/ a similar concern. You seemed mistaken at first until a few threads deep, so there’s likely someone else who is just as, if not more, confused.
Usually when steam refuses to launch, it’s because there’s some Steam process that’s borked but still running. Most of the time, a simple pkill steam fixes it (yes, that includes for flstpak`).
As mentioned down thread, the runtime isn’t your problem. The runtime is what’s needed for native Linux games and I think is also used by proton (not used by Steam itself), so it’s kind of like proton for native games. Steam doesn’t use the runtime at all to launch.
If killing Steam doesn’t work, try rebooting. If that doesn’t work, try updating the flatpak. If that doesn’t work, I suppose reinstall Steam.
No, that’s an ornithologist.
An orgasm is the term used to refer to relative positions in a set.