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.
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.
What distro I’m using isn’t that helpful of a question because it’s largely a matter of taste and technical needs. I use Arch in large part because I do some rather exotic things that would be harder to set up on most mainstream distros whereas Arch just gives me a completely blank slate to work with and configure my system the exact way I want it to work. My desktop also has some server duties, it runs VMs, it has multiple GPUs and also drives my TV room independently of my main workstation area.
I usually recommend whichever distro gets you the closest to having everything the way you like out of the box as a starting point just because it’s less frustrating when most things works out of the box. The Arch experience is nothing works out of the box because it doesn’t even come with a box. Arch isn’t necessarily a bad choice even for beginners, but the learning curve is much steeper as a result and some people do like to just learn everything whereas some others prefer to start with the shallow part of the pool rather than diving it headfirst. It’s not like you have to commit to any distribution forever, you can start with something simple to use, learn your way around Linux and then you can upgrade to another distribution as your needs and wants evolves.
Plug drive in main computer, install Debian on it along with network config and SSH access, put drive back into server and power on.
I guess technically you can also make an ISO that will just auto wipe the drive and install upon booting it but you still need a keyboard to get into the boot menu.
I could understand refusing to repair it but come on at least send it back.
Mine’s running on a single docker-compose.yml and it’s like 4 services: the backend, the frontend, the database and pictrs. That’s hardly insane nor complicated nor ruining existing setups.
It’s probably one of the easiest services I’ve run in quite a while.
I don’t even bother trying with AI, it’s not been helpful to me a single time despite multiple attempts. That’s a 0% success rate for me.
Prometheus/VictoriaMetrics/Grafana are pretty good, had no issues with it and there’s an exporter for damn near anything. They’re pretty easy to custom write too.
25G pictrs
13G postgres
38G total
Seems fairly reasonable to me
If you want FRP, why not just install FRP? It even has a LuCI app to control it from what it looks like.
NGINX is also available at a mere 1kb in size for the slim version, full version also available as well as HAproxy. Those will have you more than covered, and support SSL.
Looks like there’s also acme.sh support, with a matching LuCI app that can handle your SSL certificate situation as well.
The concern for the specific disk technology is usually around the use case. For example, surveillance drives you expect to be able to continuously write to 24/7 but not at crazy high speeds, maybe you can expect slow seek times or whatever. Gaming drives I would assume are disposable and just good value for storage size as you can just redownload your steam games. A NAS drive will be a little bit more expensive because it’s assumed to be for backups and data storage.
That said in all cases if you use them with proper redundancy like RAIDZ or RAID1 (bleh) it’s kind of whatever, you just replace them as they die. They’ll all do the same, just not with quite the same performance profile.
Things you can check are seek times / latency, throughput both on sequential and random access, and estimated lifespan.
I keep hearing good things about decomissioned HGST enterprise drives on eBay, they’re really cheap.
Wordpress or some of its alternatives would probably work well for this. Another alternative would be static site generators, where you pretty much just write the content in Markdown.
It’s also a pretty simple project, it would be a great project to learn basic web development as well.
I can definitely see the improvement, even just between my desktop monitor (27in 1440p) and the same resolution at 16 inch on my laptop. Text is very nice and sharp. I’m definitely looking at 4K or even 5K next monitor upgrade cycke.
But the improvement is far from how much of an upgrade 480p to 1080p and moving away from CRTs to flat screens. 1080p was a huge thing when I was in highschool as CRT TVs were being phased out in favor of those new TVs.
For media I think 1080p is good enough. I’ve never gone “shit, I only downloaded the 1080p version”. I like 4K when I can have it like on YouTube and Netflix, but 1080p is still a quite respectable resolution otherwise. The main reason to go higher resolutions for me is text. I’m happy with FSR to upscale the games from 1080p to 1440p for slightly better FPS.
HDR is interesting and might be what convinces people to upgrade from 1080p. On a good TV it feels like more of an upgrade than 4K does.
Depends entirely on the bundler. They all have a watch mode, not all of them do hot reload. Hot reload is cool but full of gotchas, it’s a hack but worst case you reload the page anyway. Some probably cache on disk, I think webpack can.
But if you think about it, you either want a clean build for production, or rebuild quickly during development. Watch mode does exactly what you’d do anyway, re-run a build. And IDEs can watch its output to give you error messages.
It’s much easier to implement: just emit the code again when the file changes, and let it go through the pipeline. It’s already there in memory all figured out, no need to figure a serialization format to put on disk to load back up.
But to circle back to the original question of why use watch mode when you can just rebuild it when saving a file: you’re reinventing the wheel, and watch mode scales better and will always be faster. Yes, some people need watch mode.
The scale of things. Large projects take longer to compile and bundle because they’re made out of thousands of files and hundreds of thousands of lines of code.
Yeah, your hello program will go just as fast without a bundler, or a simple bundler. It’s when you go big, and use tons of libraries and stuff that it slows down and the advantages become clearer.
That’s especially true when using big libraries like React and dozens of plugins for it, frameworks like Next.js, SASS for CSS or CSS in JS, all the JSX, all the TypeScript. It adds up especially if Babel is also involved to transpile for older browser support.
5 minutes is a bit of an extreme use case, but the point is after the first build, live reload would still refresh your code at the same speed. So working on one page you don’t need to constantly rebuild the other hundreds of them, just the one you changed. If you target mobile platforms with Cordova or React Native then you also add a whole Android/iOS build + install + restart of the app. The same live reload would work even in that context, making the speed advantage even more apparent.
These things are designed for large enterprise projects, not for your small helloworld sized hobbyist programs.
Incremental builds are much faster as it often only need to rebuild the specific part that changed. Just re-running the build in VSCode won’t help you if the build takes like 5 minutes, but still instant with watch mode.
Hot reload also has some advantages such as not having to reload the page and lose state: it can just update the CSS live so you can quickly iterate on your styles even if you’re deep into the navigation at page 10 of a modal window.
We don’t need live reload/watch, but it sure is convenient.
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.