The problem lies in the fact that these companies are generating work for volunteers on a different time-scale and binding them to it by giving them X days before disclosing vulnerabilities. No one wants their project to have security vulnerabilities that might affect a lot of users, which creates pressure in dealing with them.
The open source model is broken in this regard, licenses need to address revenue and impose fees on these companies, which can be used as bug bounties. Game engines do this and so should projects like FFMPEG, etc. The details are complex of course, but the current status quo is abusing people's good will.
It's kind of an exploratory phase for what works sensibly with Rust's borrow checker, especially since most UI libraries/frameworks really rely on a GC.
I'm using EGUI for a all-in-one molecular viewer / CAD. It's like PyMol, Coot, GROMACS and VMD in one. If this is trivial, I would like to see what you consider to be non-trivial!
There are parts of the rust ecosystem that are only built for trivial apps (And demos, blog posts etc), but GUI is not one.
Look, your application is certainly impressive, but it's extremely basic from the perspective of a UI toolkit.
- It's not multi-window, so it doesn't have to integrate with a bunch of the OS window management affordances.
- It doesn't have any complicated typesetting or rich text editing, so you get to pretty much ignore that whole mess.
- Since it's a very visual tool that doesn't make much sense for blind folks, you haven't invested much in accessibility support.
- And so on...
This is a great use case for EGUI, and EGUI works great in this sort of UI-lite scenario. Whereas I wouldn't want to use it to implement something on the complexity of VSCode/Excel/FireFox.
And quite amazing work, so thank you for sharing. This will be fun to dive into. I'm generally liking egui but have just recently been using it, so I'm still new at it.
The most popular language by far used for writing UI is JavaScript, and the go to framework this day (React) doesn't use that though.
From the various experiments that popped up over the years, it's pretty clear that the React way works pretty well for Rust, but it's also too slow to be desirable for Rust (what's the point of using Rust for UI if you're going to have web-like performance).
And then again, making a half decent UI framework is a gigantic task, there's just not a whole lot of languages with a decent UI story at all, no matter what's the paradigm of the programming language. (And if you want a
language for cross-platform UI, I'd argue that the only one that ticks the box is JS with React in Electron and React Native, and it's not even truly a single framework).
The view part would be fine, the problem is updating the state. In a language which discourages shared mutability, most of the solutions are not terribly ergonomic.
You either end up needing to:
- handle all your state via interior mutability (i.e. Arc<RefCell<_>>)
- use a reducer (i.e. the state blob is immutable during rendering, updates are deferred via events that are delivered between frames)
- or invert the relationship between state and view (i.e. immediate-mode) which comes with it's own implementation challenges (caching immediate mode views is hard)
SEEKING WORK | Berlin, Germany | Remote or on-site | Full-stack Web Developer
Hey, I'm Ricardo, a full-stack web developer specialised in interactive experiences, with more than 10 years of experience in building creative and business applications.
> If everything is highlighted, nothing is highlighted.
This is very true, but not in the way the author thinks. Highlighting is the wrong term here after everything is colored. As long as you keep using the same color definitions, you should be able to blur your vision and still get a sense of what is described in the source code at the "infra-structure" level
Depends on people, but for most it's mainly because Stallman says so.
You still have ethics ground if you think it the same way as repairability, actively blocking ways to repairs things you bought yourself is questionable, and keeping things closed source can be seen as a way to artificially prolonge a strict dependance on your vendor by impairing your ability to resolve issues by yourself.
Not disclosing the ingredients is illegal large part of the world, and people can die if you don’t do that, so the answer is clearly yes in some sense. This is also true for some cooking techniques, like heat treatment of raw meat. I think your analogy is not the best.
Not disclosing ingredients is more like not disclosing dependencies because I am very confident that you can't go into a shop, buy a random food and then construct recipe from list of ingredients.
It does however play a hugely important role in a recipe, in a way than the choice of language doesn't play in a program (especially considering turing completeness). So the analogy is broken.
Besides nobody made the point that list of ingredients makes a recipe.
Just that it's important to know the list of ingredients for a food you're gonna eat, and that it's even illegal to not disclose them (either to the public or a regulatory body) if you sell food.
As someone who also believes closed source software is unethical (though full of nuance), I don't appreciate the abrasive and combative (and frankly rude) way you are engaging on this. You're so epitomizing the rabid stereotype that part of me thinks you are just trolling and don't actually believe what you are saying.
If you actually care about this, stop alienating potential allies, and ideally start making arguments to support your case instead of telling people to RTFM (which in this case is even worse because "the manual" isn't as much of an authoritative mic drop as you seem to think it is).
This is the first paragraph after the initial quote defining "free software".
> We campaign for these freedoms because everyone deserves them. With these freedoms, the users (both individually and collectively) control the program and what it does for them. When users don't control the program, we call it a “nonfree” or “proprietary” program. The nonfree program controls the users, and the developer controls the program; this makes the program an instrument of unjust power.
It seems safe to say the author thinks that one creating "an instrument of unjust power" for oneself is unethical. Though, perhaps if the commenter in question pulled that quote out of the article, it could have helped their point.
You don't have to agree with it, but I think it's fair to parrot a take from people who have invested a lot of time and effort into considering why free software is good.
The linked page has a clear explanation for why one might consider nonfree software to be unethical.
Sometimes people take the time to read and understand something and conclude that this is the best way to express it, better than they themselves can paraphrase.
And sometimes they just collect opinions and follow suit, instead of forming their own ones. How do you know which one happened here, are you a mind reader?
> How do you know which one happened here, are you a mind reader?
If you admit that they could be doing one of two things ("And sometimes ...") but you assume it's actually one of them in particular ("I think they asked for your take, not GNU's."), then this question could similarly be asked of you.
A bigger problem with my model is that it's a false dilemma. These are both just characterizations. Both can be true at the same time just fine, and so can neither.
It even does my own sentiment poorly. My actual issue with this whole exchange was not that their thoughts are unoriginal (although I'd be surprised), but that this way of responding I find extremely lazy and disrespectful, as well as generally unreasonable. They were asked for their opinion. It doesn't have to be good, it doesn't have to be rigorous, it just has to be theirs.
Linking out to some reading material and adding nothing else of substance fails even this most basic expectation. It's a discussion thread, not a newsletter. But then just like in the other subthread where the person above found me from, I'm sure they'd argue that this is just, like, my opinion. And that it sure is.
Could ask the same from you really, but then you followed me here out of spite from the other subthread to just loosely regurgitate another person's reply [0], along with your lackey [1], trying to make it a touch more hostile on the way, so I think I do know the answer to that one...
> If you're not interested at all, why did you even join the conversation?
Or was this a genuine question? I don't think you do those though. Are you then maybe getting tripped up on your own dumb headcanon? Cause honestly, given that this would be the third time in this thread that you're conjuring up a strawman and twisting words, you have to appreciate I have a hard time believing anything coming out of your mouth (keyboard?) at this point. It's almost as if there was a reason I went off about what I did, and it's coming back to bite you in the ass now...
To you, is a suggestion for someone to explain their own thoughts in their own words, rather than link to someone else's, a sign of no interest at all? Did I really say that I wasn't interested in what their take was, or did I say that I wasn't interested in receiving another barrage of GNU links? Careful, the latter one doesn't even require thinking, only bare minimum intellectual honesty, seemingly your Achilles heel.
When it comes to CSS, there will be the same vendor issues that you have on websites. It's not a magic bullet.
reply