egui is cool but it’s an immediate UI kind of thing, that’s usually used in video games as you’re constantly re-rendering the whole thing anyway.
A more fitting UI library would be Iced, which is also what System76 is building their COSMIC desktop environment on.
It does claim to support the web too, although not via HTML which brings some accessibility concerns. I’d expect performance to be very good otherwise.
I get about 350-400 both ways which AFAIK is what my Unifi AC-Lite tops at since it’s WiFi 5 and it’s only got 2 antennas and tops at 80MHz channels. I get about 200-250 on my phone (1+8T) which I think is single stream.
Everything indicates me that’s as best as it can be with the set of hardware I have. Signal is solid, latency is solid.
You’ll need 802.11ax and/or more MIMO streams to get higher speeds, and/or 160MHz/320MHz channels.
I’m not saying to use native toolkits like Qt or GTK, those indeed have problems. What React Native does is somewhere in-between: it’s an abstraction that produces decent results between platforms including the web.
It uses slightly higher level abstractions that work a lot like the web for rendering, you still get your boxes and a subset of CSS properties. But on web it’ll compile to flexbox or grids, on Android it’ll compile to something like a LinearLayout or some other kind of layout the OS understands. On web a <Text> will compile to a <span>, on Android it’ll compile to a native text element. On mobile where you need the performance the most, you otherwise end up rendering a web page that will then eventually end up doing the same thing back to display it natively, but with all the downsides of a web view.
This performs way better with basically no downside for the web version, has the majority of the flexibility one needs for responsive layouts but it’s way more lightweight when you do target native. On native you can just render it all yourself for really cheap, like any native toolkit would. You’re your own toolkit.
They will never look native, but at least all the rendering will be native. Most companies have their custom UI theme anyway, native widgets rarely gets used anyway.
We’re talking Electron replacement after all, it’s not like apps made with it look anything native. But if at least they performed like native apps by skipping the web views and all the baggage it brings with it, that’d be great.
For the end user, its main weakness is that complex pages can be pretty slow to render if not coded well. It’s not that bad either. You wouldn’t be like “oh this is a React site, yuck”, they’re all like that these days for the reasons you’d expect.
As for React Native, its main issue is the communication between the JavaScript browser-ish environment and the Java/Kotlin native environment that can be costly because every has to be serialized (meaning, converted to some type of data structure both sides can understand) and deserialized, so complex screen updates don’t scale too well.
It’s easy for developers to accidentally trigger much bigger and much more expensive rerenders than expected. If you see whole second long page hangs on some websites as new content loads in that’s usually what happened.
For developers, it’s complicated, you kind of need to experience it to understand the footguns.
React was born to solve one particular problem at Facebook: how can we make it so any developer can jump on any part of the UI code and add features without breaking everything. One of the most complicated aspects of a website is state management, in other words, making sure every part of the page are updated when something changes. For example, if you read a message in your inbox, the unread count needs to update a couple places on the page. That’s hard because you need to make sure everything that can change that count is in agreement with everything that displays that count.
React solves that problem by hiding it away from you. Its model is simple: given a set of inputs, you have a function that outputs how to display that. Every time the value changes, React re-renders every component that used that value, compares it with the previous result, and then modifies the page with the updated data. That’s why it’s called React, it reacts to changes and actions.
The downside of that is if you’re not very careful, you can place something in a non-ideal spot that can cascade into re-rendering the entire page every time that thing updates. At scale, it usually works out relatively okay, and it’s not like rendering the whole page is that expensive. There’s an upper cap on how bad it can be, it won’t let you do re-render loops, but it can be slow.
I regularly see startups with 25MB of JavaScript caused by React abuse and favoring new features over tracking down excessive renders. Loads the same data 5 times because “this should only render once” and that turned out to be false, but it displays correctly. I commonly see entire forms being re-rendered every character you type because the data is stored in the form’s state, so it has to re-render that entire tree.
But it’s not that bad. It’s entirely possible to make great and snappy sites with React. Arguably its problem isn’t React itself but how much it is associated with horrible websites because of how tolerant to bad code it is. It’s maybe a little bit too easy to learn, it gives bad developers an undeserved sense of confidence.
E: And we have better solutions to this such as signals which SolidJS, Vue and Svelte make heavy use of. Most of the advantages with less problems.
Anyway, that part wasn’t relevant at all why I don’t like React. The point is, skip the web, you don’t really need the web. React Native skipped the whole HTML part, it’s still JSX but for native app styled components for UI building. The web backend worked very well, your boxes became divs with some styles. It pretty much just worked. Do that but entirely in Rust since Rust can run natively on all platforms. Rust gets to skip all the compromises RN needed, and skip the embedded browser entirely. Make it desktop first then make the web version, it’ll run just as well and might even generate better code than if a human wrote it. Making the web look native sucks but making native fit web is a lot easier than it looks. Letting go of HTML and CSS was a good call from React Native.
I wish we went the other way around: build for native and compile to HTML/CSS/WASM.
For me the disadvantage of Electron is well, it doesn’t have any advantage or performance improvement over the browser version for 99% of use cases, and when you shove that on a mobile phone it performs as horribly as the web version.
People already use higher level components that ends up shitting out HTML and CSS anyway, why not skip the middleman and just render the box optimally from the start? Web browsers have become good, but if you can skip parsing HTML and CSS entirely and also skip maintaining their state, that’s even better.
I had the misfortune of developing a React Native app, and I’d say thinking in terms of rows and columns and boxes was nice. Most of RN’s problems are because they still run JS and so you have to bundle node and have the native messaging bridge, and of course that it’s tied to the turd that is React. But zero complains about the UI part when it doesn’t involve the bridge: very smooth and snappy, much more than the browser. And the browser version was no different than standard React in performance.
I like that it’s not yet another Chromium one at least.
It’ll depend a lot on your experience. I can just install Arch without reading the wiki at all in about 5 minutes for something fairly vanilla. If you’re comfortable with Linux then following the wiki won’t be too hard, took me maybe 2-3 hours on my first install before I had my DE and everything all set up (12 years ago). If you’ve never used Linux before and take the deep dive then it could take hours and days depending on how fast you can absorb all that information.
“Easy” is very subjective, there’s stuff that’s so dumbed down for the sake of “easy” that it makes my life harder when I need to do more complex stuff. I know people for whom linear algebra in 11 dimensions is easy for them to do and solve. Easy is relative to your own personal experience level and what you’re trying to accomplish.
Install it in a VM as a test run, you’ll see by yourself.
Obligatory https://youtu.be/xDLvUqhwHZc
The problem with Fedora and especially the atomic versions is that when you Google “how to do X on Linux” you pretty much always get information for Ubuntu and Debian derivatives. The atomic versions have it mildly harder because now you also have to learn how immutable distros work, and you can’t just make install something from GitHub (not that it’s recommended to do so, but if you just want your WiFi to work and that’s all you could find, it’s your best option).
It’s not as bad as it used to be thanks to Flatpak and stuff, but if you’re really a complete noob the best experience will be the one you can Google and get a working answer as easily as possible.
Once you’re familiar and ready to upgrade then it makes sense to go to other distros like Fedora, Nobara, Bazzite, Kionite and whatnot.
I don’t like Ubuntu, I feel like Mint is to Ubuntu what Manjaro is to Arch, Pop_OS is okay when it doesn’t uninstall your DE when installing Steam. But I still recommend those 3 to noobs because everyone knows how to get things working on those, and the guides are mostly interchangeable as well. Purely because it’s easy to search for help with those. I just tell them when you’re tired of the bugs and comfortable enough with Linux then go start distrohopping a bit to find your more permanent home.
API documentation isn’t a tutorial, it’s there to tell you what the arguments are, what it does and what to expect as the output and just generally, what’s available.
I actually have the opposite problem as you: it infuriates me when a project’s documentation is purely a bunch of examples and then you have to guess if you want to do anything out of the simple tutorial’s paved path. Tell me everything that’s available so I can piece together something for what I need, I don’t want that info on chapter 12 of the example of building a web store. I’ve been coding for nearly two decades now, I’m not going to follow a shopping cart tutorial just in the off chance that’s how you tell how the framework defines many to many relationships.
I believe an ideal world has both covered: you need full API documentation that’s straight to the point, so experienced people know about all the options and functions available, but also a bunch of examples and a tutorial for those that are new and need to get started and generally learning how to use the library.
Your case is probably a bit atypical as PyTorch and AI stuff in general is inherently pretty complex. It likely assumes you know your calculus and linear algebra and stuff like that so that’d make the API docs extra dense.
On top of everything the others have said, another way this isn’t possible reliably is servers that just accept all email and forward it to a catchall address.
Some also have trap addresses where sending email to it will result in putting that address directly into the spam filter and everything coming from it feeds into training the spam filter. I’m an individual, not a company, so all the common IT, HR, support, press, sales, whatever addresses are traps.
When websites force me to enter an email, I enter one of the traps so everything they send me and everyone they share that email with gets the banhammer instantly, and I can track which asshole website did that to me as well.
Yeah mine’s doing that too, and my dmesg is flooded with USB disconnect and reconnects.
The thing probably is overheating and shutting off. I believe I’ve seen videos of them catching fire too, not sure if it’s that one or another webcam that looks similar.
Mine’s on a USB hub with buttons for each port so I just leave its port off until I need the camera and only turn it on when needed.
Dracut is the correct way to do this on Fedora so nothing else needs to be done. Then I’m not sure why it’s not taking it.
Did you rebuild your initramfs? The files needs to be available pretty early during boot and that’s probably why it still seems the old one.
The fuck are you doing that it takes an hour to do with systemd? My experience has been the total opposite: drop a file or two somewhere, probably a symlink and done. Even encrypted ZFS root in initramfs was surprisingly easy to set up.
Cool but what does it have to do with open-source?
There’s a bug with explicit sync? I’m running patched KWin 6.0.5 and no issues whatsoever with Firefox.
The problem with that is that the rest of the ecosystem keeps moving on, and the more time passes the more left behind you are. So you stick with old versions of whatever you use and when the time comes to upgrade it hurts even more because it’s not just the OS that works differently but also all the software you’re using including Python, Ruby, PHP, NodeJS or whatever your software stack is built on. So you have to upgrade all of that code too. At some point you might as well start over from scratch which just makes it even harder and daunting to tackle to you increasingly push it further until you hit the 12 years and you’re forced to do it with time constraints
The proper solution to critical systems you’re too afraid to upgrade is to… upgrade and redeploy them more often in test environments so you’re not afraid of upgrading the system. And the very companies that would pay for the 12 years of support are the ones that really should have the whole thing fully automated and fully tested.
What kind of filename do they have? How big are they?
My guess would be that they’re Android thumbnail files or some sort of hidden metadata file. Possibly some raw jpeg because all the parameters are expected to be fixed size so they didn’t bother with the header. Or it’s a custom header.
But even then, that’s a lot of zeros for an image format.
Does it seem to have a JPEG header later in the file? It could be a header followed by a normal JPEG file too.
virtiofs is amazing, got my entire Steam library on it. It’s like it’s not there, NVMe speeds no problem.