Really good hardware for the price.
They fixed the worst thing about SteamOS: It's now got an Arch base.
They're definitely overcharging for storage, but I imagine it'll be easy enough to modify one, so it probably doesn't matter much.
Why is any company having more USB-2 slots than USB-3 these days?
Going with a relatively low resolution compared to modern ones is actually a surprisingly smart move, given how small the display is.
Almost certainly has to do with cost and PCI-E bandwidth. Mobile chips like this only have so much bandwidth, and USB3 requires more dedicated bandwidth than USB2, not to mention more complicated circuitry that drives up price. And when your expected use case is attaching keyboards and mice, which generally are USB2 only anyways, it reduces the cost and bandwidth needed to support that many ports.
That's exactly what we call a "Mobile" chip in the x86 CPU market.
The mobile phone grade chipsets you are probably thinking is probably called "Embedded" chip in the x86 market. ("Embedded" chips is wider than a mobile phone though)
edit: On closer look that's comparing the Switch without controllers (297g) to the Steam Deck with controllers (669g). The Switch with controllers is 398g, so the Steam Deck is only ~1.7x times as heavy - though that's still a lot of extra weight to hold in your hands.
Tingling in your hands sounds worryingly like RSI, I’d see a doctor about that.
I've had success with daily low reps, but some longer intervals may work too. Once they've been primed, muscles grow when you rest, so rest is crucial.
1. https://www.steamdeck.com/en/tech
edit: crtl-f mistake, that's the docking station
That issue alone is bad/wide-spread enough they should replace joycons for free.
I think it's not a case of "having more USB-2 slots than USB-3 slots", I think it's instead a case of "having precisely two USB-2 slots", no matter how many USB-3 slots there are. The reason for exactly two USB-2 slots is obvious: one of them is for the keyboard, the other one is for the mouse. Neither the keyboard nor the mouse need more than USB-2, so there's no reason to have the more complex USB-3 hardware for these two ports.
Other than those two ports, it makes sense to have the rest of the USB ports be USB 3, which seems to be the case here, even though there's only one (the USB-C port seems to be meant to be always plugged into a charger, so it might also be USB-2 only).
That could have saved some time on tooling/packaging adaptions.
Not that I dislike Arch Linux, I run both Arch Linux and Debian (Stable on servers Sid on laptop).
Not only is having new stuff good from a feature and hardware-support standpoint, but, paradoxically, new software seems to have WAY less bugs than old software. (I assume this is because devs are mainly on the new versions and don't care about old versions that much.) Try using CentOS 7, with ancient, should-be-rock-solid versions of apps. Dolphin crashes every time you load into a large directory. Kate's keybinds are broken. Tmux refuses to support 256 colors. I get none of these issues on Arch or Manjaro.
I'm also sure that Valve's system is going to have a smaller set of software than I'd use on an Arch desktop anyway, so there's less surface area for stuff to break.
Maybe the people using lots of AUR are complaining a lot, and the people who don't just quietly switch distros?
I'm sure that Valve is going to install a much smaller set of core software than a typical desktop, though.
I have the exact opposite experience, I used to use sid and had to do full-blown reinstall every couple months because e.g. dpkg would break too much and I wouldn't be able to install anything, or once, even boot and ended up migrating to arch despite the warnings - never had to reinstall the distro once since then
That said, never had to reinstall either of them. Had my system broken by pacman in ways dpkg would handle much better, but it was fixable anyway.
With the opi package you can install: chrome, codecs, dotnet, msedge, msteams, plex, skype, signal, slack, teamviewer, vivaldi, vscode, vscodium, zoom and more.
Brave is app i am missing so far, but having the newest version KDE and other software that required a PPA on Ubuntu is pretty nice.
And it feels much snappier installed on a SATA SSD than Mint from a NVME SSD on the same machine!
The auto-snapshot feature on updates was really cool, and direct integration then (almost 10 years ago for me) was ahead of most other distros IMO.
I then setup Arch to be more confronted with the things that actually go on under the hood, learned a lot and had generally a good experience with it. A bit later I got a job where Debian plays a key role, that sealed the deal on using Debian and Arch only for me (remembering the usage of two package managers is enough for me ^^).
But I have good memories of openSUSE, and it was the distro that I first used "full time", even introduced me to Linux to some degree (I dabbled a bit around with Ubuntu and Knoppix before).
(My go-to though)
Debian is in general really rigorous with ABI/Symbol versioning, dependencies and packaging in general - there are some outliers, but most of the packages in Debian is just high quality work.
On the other side is Arch Linux, where they do not even care about Kernel ABI bumps, which are trivial to detect and track, so if you pull in a kernel update you cannot load any new module, as they just overwrite the modules of the running kernel - I used it, but I find that still lunatic!
Nothing like having some complex workspace setup and then needing to connect to a VPN/WireGuard network but also forgetting to preload that module (I just load all possible relevant on start nowadays), forced a reboot, nothing lost but tedious.
On Debian this and other things where you're in limbo while some library version mismatches, or some AUR package is depending on another one, won't ever happen on Debian. It has its disadvantages, but they certainly dot their i's.
Arch is still a better choice because gaming is generally using cutting edge software.
It works great if you mostly stick to official Debian packages through and through.
I need external repositories (albeit rarely) with Arch too though and that has never caused a problem.
If you want iPhone ease Linux use Ubuntu based distros. But traditionally Linux hadn’t been single click easy. Much like smartphones weren’t originally iPhone level easy.
Polite edit: if you’re a Linux noob start with a vm or live disk Ubuntu image and play around. If you like computers and understanding them, you’ll find the lessons you need as you need them by searching the web. Then you’ll install a bunch of distros and understand what I mean.
This makes buying the model with limited storage a bit of a no-brainer. I'm glad Valve supports external storage.
I think for the types of games I’d want to play on it (emulation) that’d be just fine, but for some it could be a bit annoying.
I think they should have gone with a faster interface though.
But then, it cost 60€ for 512 GB, and that's way more price effective for most. At least on the Switch, loading times are not that noticeable imo.
I'm a little surprised they didn't go with something like Fedora. The kernel / drivers are kept just as up-to-date as Arch but the rest of the system is a little more stable.
The most important libraries for Steam are things like Mesa, which Fedora updates on a rolling basis along with the kernel.
https://src.fedoraproject.org/rpms/grub2/tree/rawhide
Some of these are pretty questionable, particularly disabling the use of "grub-install" on UEFI systems (https://bugzilla.redhat.com/show_bug.cgi?id=1917213)
Mesa and the kernel would be less important, as all the hardware needs to be supported by them on release.
That's not the case w/ the Fedora release cycle. Like I said, it's only slightly behind Arch.
I guess I don't understand what complexity there is to remove in the first place.
I'm not talking about the workflow for an end-user: Valve is definitely not going to force people to run terminal commands to update their systems. While pacman's update workflow is way simpler than dnf's, it's just not relevant here.
I was primarily talking about the complexity of the tool itself, of updates, and also the complexity of packaging. Arch is a packager's distro, and much of the foundation Arch is built on is the Crux-style "as simple as possible" mindset. There's much less that can go wrong when you're doing much less with much smaller tools.
I'm not hating on dnf or rpm, here, for the record. They're fine tools for their use cases.
1. Fedora is not a rolling release, so you don't get every single kernel point release like you do in Arch.
2. Steam does not want to do a full Fedora 30 to 31 upgrade every six months. They want to roll. It's a better model, especially when kernel/drivers are improving gaming quickly.
3. Arch has a stable base and gets small updates every day. Regular software services tell us this is a better model than infrequent large updates. Things like RHEL are the exception, but take years of QA, and leave you with old drivers in between releases.
Wrong. The kernel and mesa stack rolls and is rebased regularly throughout the life of a Fedora release. Fedora is prepping for a rebase to Linux 5.13 for both Fedora 33 and Fedora 34 now: https://fedoramagazine.org/contribute-to-fedora-linux-kernel...
Fedora rolls the kernel. I'm on Fedora 33 (a full release behind), and yet I still have kernel 5.12.15, the exact same as Arch currently has. I don't have any custom repos configured.
On rare occasions Fedora even gets new kernels faster than Arch, but usually it's less than a week behind.
>2. Steam does not want to do a full Fedora 30 to 31 upgrade every six months. They want to roll. It's a better model, especially when kernel/drivers are improving gaming quickly.
Fedora gets constant Mesa updates as well, it's not pinned. Admittedly it's 2 months behind Arch (21.0 vs 21.1)
My favorite part of Arch is the rolling packages and my least favorite is the rolling kernel. I dislike having to reboot so often.
You will not get security and bug fixes but that's what's bothering you, I think.
Because it's cheaper to produce and easier to design for USB 2. The cpu and chipset are limiting factors as well.
https://www.amd.com/en/products/chipsets-am4
Scroll down to the table at the bottom of the page to see what AMD's chipsets can support.
What caused this shift is that the current generation of consoles shipped with SSDs. The PS5 and Xbox Series X/S both shipped with NVMe storage standard. Games going forward are designed with this baseline in mind.
The reason this affects game technology is because it changes the tradeoffs. You always wanted assets to load quickly, since forever. The amount of time it takes to load an asset has two parts that contribute: I/O time and the CPU time spent decompressing.
In the past, storage was more precious and slow, so your game would load much faster by compressing the data. NVMe users would never see worse loading times than SSD or HD users, so you'd just compress everything, and the NVMe users would see a slight benefit.
Now that NVMe is a reasonable minimum requirement, you can ship a game that uses uncompressed data on disk. People with NVMe see faster load times, and people without them see slower loading times, possibly MUCH slower.
When I say "uncompressed", I just mean "uncompressed, relative to the runtime representation" which may still use compression, like ASTC.
The situation with the Nintendo 64 is remarkably similar to what's going on now... because the Nintendo 64 had such a fast storage system, games could "easily" load assets on the fly. The system had only 4MB of RAM, which seemed like a very severe limitation, but you could make very expansive areas in games by streaming assets from the cartridge while playing. It was fast enough that you could load some assets from the cartridge into RAM, and they would be available to render during the same frame! These are the kind of technological changes that are going to happen inside engines, now that NVMe storage is more common.
I put "easily" in quotes because nothing about Nintendo 64 programming is easy.
As fast for sequential data, but at least an order of magnitude more IOPS.
Just take a look at the painfully long loading times on the Switch to see the difference.
UHS-III works with Micro SD cards and it's supposed to give you 624 MB/s. SATA 3.0 is supposed to give 6.0 Gbit/s, or 750 MB/s.
That's only 20% faster. I'm sure the real number is different due to overhead, but how different can it be?
I'm not going to be shocked by low Switch performance, since the Switch is basically an obsolete mid-range phone, in terms of specs.
Sure, might change in the future, but no game right now uses the future APIs (direct storage) that might lead to bigger differences. Which is no surprise, as Windows 10 does not support it.
there are plenty of graphical frontends for updates on Arch.
Another big thing is more recent glibc and mesa for instance which can be huge for performance. Also, Arch makes it fairly easy to rebuild all packages with optimizations for a given CPU ; for instance someone recently made a test of arch built with x86_64-v3. Also there's the way packages are built (much simpler than with debian), etc.
As for packages, why does SteamOS need packages? They can just make one large update package that includes all library updates for the latest SteamOS version. Or are they expecting users to say "Oh I want to update just this one library"? Seems like a huge missed opportunity to make SteamOS a "stable target" that Linux devs can make games for. But if everyone is like "I want this weird glibc!" then that's impossible.
The adage that you have to use a terminal if you want to run a distro has been out of date for over a decade.
USB 3 is clocked at 5 GHz, which requires more power still. Just having a transceiver capable of that frequency enabled will draw a significant load from a battery, regardless of whether you're using the bus for power delivery.
Most of the prospective users don't need more USB-3 ports than they have.
SteamOS 2 was Debian-based