It’s instance dependent and likely small on bigger instances to reduce storage costs as it can grow really big. I don’t know the exact number for lemmy.ml.
It’s instance dependent and likely small on bigger instances to reduce storage costs as it can grow really big. I don’t know the exact number for lemmy.ml.
You have to keep in mind, when you write JavaScript, there’s an entire runtime written in C++ to run it under the hood, with some crazy optimizations to make it reasonably performant. What type of languages do you use to write that runtime? A systems programming language like Rust and C++.
You don’t have to use Rust if you don’t like it. Not everything must be written in Rust. The whole pick a language also involves a lot of picking your tradeoffs. Picking a interpreted/JIT language for speed of development is a perfectly valid tradeoff, but not one you can universally make. Sometimes the performance cost becomes really expensive currency-wise, where you can save thousands of dollars on server costs by simply having a more efficient application that only needs a fraction of the hardware to run it. Even in JavaScript, a fair chunk of libraries you use end up calling to C++ native code because it would be too slow in pure JavaScript. Sometimes the tradeoff is pick the popular language so it’s easier to hire for cheaper.
Even at the dawn of time, most computers shipped with a variant of BASIC so people could write simple applications easily. But if you wanted to squeeze out every bit of power in your Apple II or C64, you sure did reach for assembly. Assembly sucks so we made C, then C++. Rust is still a language that’s made to eventually compile to assembly/binary and have the same performance as if you wrote it in assembly.
And low spec hardware still exists: the regular Pis have gotten pretty fast but if you run on an RP2040 then suddenly, you’re back in like 300MHz dual core land with pitiful amounts of memory, so you do need to write optimized and fast code for those.
Rust’s type system is actually really, really good. Most of the time, if it compiles it runs. It eliminates a ton of errors other than memory safety: the system is so powerful you can straight up make invalid state unrepresentable. You can’t forget to close a connection, you can’t pass the wrong data, you can’t forget to unlock a lock. It does a lot more to enforce correctness of a program well beyond memory safety.
Don’t worry about it, the frontends usually take care of using alternate sources if you want to:
You mean you’re not actually supposed to spend 2 hours daily unfucking everyone’s shit during the standup turn by turn?
I’ll take the autotools over Gradle, that’s how much it sucks.
I don’t think you can, and I think it makes sense: it would be weird for the compiler to unexpectedly generate hidden variables for you.
For all the compiler knows, the temporary variable could hold a file handle, a database transaction, a Mutex, or other side effects in their Drop implementation that would make when it’s dropped matter. Or it could just be a very large struct you might not expect to keep around until the end of the function (or even, the end of the program if that’s a main loop).
So you should be aware of it, and thus you need the temporary variable like you did even if you just immediately shadow it. But at least you know you’re holding on to it until the end of the function.
It doesn’t by default and design, but that doesn’t mean it can’t be implemented through a special protocol or compositor plugin.
This also protects against windows, not processes of the same user. You can bypass the problem by simply wrapping the game and your overlay in a nested compositor like gamescope. From there you control the compositor, so you can do whatever you want.
And it’s still secure because it only lets you overlay over stuff from your own Wayland clients spawned by your overlay wrapper, none of the user’s other windows, so you can still trust your password manager and such.
There’s two main options to approach this: either you inject into the game like how MangoHUD does it, or you make an overlay window that your window manager/compositor helpfully places on top for you.
The second option is pretty simple as any GUI library will give you the window, you just need some help from the compositor side to do the rest. That part can also be pretty easy thanks to Wayland nesting: you can use whatever compositor you want for this, not just the one from your DE. Gamescope for example might work, if not wlroots+layer-shell.
You can also be your own nested compositor by using Smithay, which is in Rust and was made by System76 to be the library behind COSMIC’s compositor. Looking at the examples, it looks not too crazy to use. Then you just run the game under yourself and you can do whatever you want.
Injecting into the game isn’t too crazy either, you compile to a library and force load it with LD_PRELOAD and override some OpenGL/Vulkan functions that lets you add your own draw commands on top before the frame is finished.
I think avoiding injecting into the game is cleaner and easier as you’re completely independent from the game client, so you won’t crash the game and you can also just test out your code as a regular window, and restart it mid game. Injecting would also trigger anticheat if present. Which, what you’re doing kind of is, even though anyone could also just pen and paper it.
Manipulating the game can be a lot of fun, more than the game itself. In a way, it kind of becomes like a higher level kind of game. When done appropriately and not ruining other people’s fun, that is. I’ve had good fun on friend’s private servers and giving their shit code a good stress test.
I have zero respect for those that just download cheats and use them to pass off as skilled and ruin the fun for others. It’s like ethical hacking: do it with permission or at least be transparent about it.
There’s game servers out there to play against other cheaters, and it can truly be hilariously broken and entertaining. I’ve also been quite fascinated by Minecraft servers like 2b2t where cheating is basically necessary to survive at all. The exploit content and drama that have come out of this server is bonkers. But everyone knows they’re playing against cheaters, the fun is seeing how you can outcheat your opponents.
There’s also the whole speedrunning community, the ways people have broken games wide open. Fascinating and very entertaining stuff. The skills you need to perform a lot of those glitches are insane and extremely challenging. Hours of grinding to get frame perfect glitches work, several times during a run. It’s a whole new puzzle, with so many more variables.
Why would someone cheat on games like CS2, Apex, Valorant and the likes, that I don’t know. Some people are really just kind of losers I guess. I personally don’t see the appeal, I’d want to be famous for the cheats and not even compete with non-cheaters because that’s just plain unethical and unfun. There’s also a big difference between finding dupes in Minecraft vs an aimbot in a competitive shooter.
Also, lame article? 😖
It’s pretty short, it could be improved with benchmarks or at least some examples of how that would be implemented efficiently. Maybe a bit of pros and cons, cursor pagination for example doesn’t handle “go directly to page 200” very well. I’ve also seen some interesting hacks to make offset pagination surprisingly fast with a clever subquery.
I wouldn’t call it lame though.
If you use ext4 or other filesystem that supports fscrypt, you can use fscrypt to encrypt specific directories.
There’s also gocryptfs for a fuse-based userspace implementation.
ZFS has built-in encryption: https://klarasystems.com/articles/openzfs-native-encryption/
It’s amazing how people just make things up. I genuinely have no idea where you got these definitions unless it was some hole on Reddit or similar.
I’m not claiming anything I said is facts, just the way I understand it to be/how it had been explained to me quite a while ago. I could absolutely be wrong, if that’s the case I’ll gladly retract my comment based on new (to me) information. I’m far from qualified to give an authoritative answer on this topic.
The way I understand it is “the government decides to build a factory because the country needs a factory” vs “the people of a region get together and build a factory because they want one”. Well, in either case nobody really owns the factory (compared to capitalism), but rather who’s in charge of it, who decides who works on what and how it comes to be.
Unfortunately the only examples of communism we’ve seen are authoritarian regimes like the Soviet Union, and currently North Korea and China (sort of). I don’t think we have a true socialist community that’s not some form of capitalist hybrid, let alone post-scarcity communism or socialism without massive corruption tainting it.
The federation tends to let member planets be independent, the federation doesn’t come in and be like “we own your planet and we provide for you in return we take everything”, so it’s definitely leaning socialist.
The main difference is who owns the means of production. In communism, the government does. In socialism, the people do.
Both aim to provide for the population at large and not just benefit to a few rich elites that own everything, but socialism is a bit more robust against tyrannical governments.
The setting is “Keep launchers separate”.
Alternatively you can also remove all the launchers in the task manager, and just add the launchers directly to the panel. It will never move and will always launch a new instance.
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’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.
Postgres 16 and pict-rs 0.5.16, but neither are critical it’ll just miss features. Like if you use pict-rs 0.4.x then you can’t use the image proxy, but you shouldn’t anyway.
Also, series F but they’re only deploying on one server? Try scaling that to a real deployment (200+ servers) with millions of requests going through and see how well that goes.
And also no way their process passes ISO/SOC 2/PCI certifications. CI/CD isn’t just “make do things”, it’s also the process, the logs, all the checks done, mandatory peer reviews. You can’t just deploy without the audit logs of who pushed what when and who approved it.