• 0 Posts
  • 910 Comments
Joined 3 years ago
cake
Cake day: June 17th, 2023

help-circle

  • This sounds all well and good. But I find in practice it never works very well. Too easy to gain a conflict which then messes with the stash (things remain in the stash and need to be dropped if you remember to). I always found it a pain to manage.

    These days I just commit everything to master. When I start work on one feature to realise I need something else or to refactor something else first the I do that work, patch commit the changes, create a branch and checkout a new worktree, cherry pick the changes and push that branch to create a pull request. Then continue with the previous work while I wait to get the previous work merged.

    Have a script which basically lets me do all that with a single command. And I never need to manage the stash. The only time I use the stash is with a rebase or pull etc with the --auto-stash flag. Which pops things off when it’s done anyway. The stash only really works for very temporary stuff like that.


  • Basically they don’t. It is the scheduling pinning background processes to a subset of the cores leaving others free for foreground tasks that is what helps.

    The E cores just give a convenient way to split them. They could have done the same thing on intel macs or any other computer that does not have e cores.

    The big benefit to e cores is they are more power efficient for tasks that don’t need performance.


  • Someone once told me somewhere, that if I am trying to learn rust, I should learn C first, so that I know how to shoot myself in the foot, learning to avoid doing so

    This is stupid advice. If you want to learn rust then learn rust.

    So thats what I did (somewhat) for the past 6 months. I wrote some stuff in C

    In that time you are no closer to learning rust. If you started with rust you would know it by now. Rust is not harder to learn then C. If anything C is harder to learn as it’s compiler doesn’t guide you at all.

    You don’t need to learn C to appreciate the borrow checker. I find beginners just accept whatever they are first taught. It is only really those that come from C the put up a bigger fight when learning rust.

    And 6 months in a language without a borrow checker is not really long enough to learn the reasons why a borrow checker is useful. Not without a good guide that focuses on that. Which most c books don’t. The best way to learn it is with rust that actually tells you when you mess up.





  • nous@programming.devtoLinux Questions@lemmy.zipSystemd Timer units
    link
    fedilink
    English
    arrow-up
    5
    ·
    edit-2
    8 days ago

    Note that you can use systemctl list-timers to see all active timers including when they will next run and when they last ran. This is very useful for seeing if you have set things up correctly.

    There are multiple ways to do this as well. You can do

    OnCalendar=Sun 03:00
    Persistent=true
    

    To run every Sunday at 3am. And will run immediately when activated if the last time was skipped due to the system being off. Think that is the closest to your cron job.

    You can also

    OnCalendar=weekly
    Persistent=true
    

    If you don’t care when it will run. This is equivalent to Mon *-*-* 00:00:00.




  • You have picked some weird hills to die on there.

    for x in list:

    This is fine. Many languages now do it. The extra brackets around a for or if dont really add any clarity or make things easier or harder to read. This is the type of thing you just get used to and prefer what you are used to. You get over it quickly.

    Why would you provide a way to type parameters but don’t enforce it at runtime?

    This is a bit stupid, but really is legacy reasons for it. Since it didnt use to have static type declarations and wants to remain somewhat backwards compatible it needs to ignore them at runtime. But as a JS and PHP developer you should be used to this. Both do the same thing as python here with types (well, TS for JS and the many other attempts at getting types into JS). So it is weird that you are singling out python for this behavior.

    Why so many different ways to declare an array-like structure? Tuples, Sets, Dicts, Lists?

    DIcts are not array like here. Tuples sets and lists are all common is many languages as well. PHP is a real weird case here given everything, even arrays are effectively a dict - that is a strange language design feature. But Java is way worst for different types of array types in the language.

    I’m mainly using it because of interoperability, easy to setup, i

    What? I hate setting up python projects. Each one wants to use a different dependency or version manager. Yeah you might have python on most systems but they are all different versions and python is famously terrible at backwards compatibility. It seems every few versions they throw something in the breaks some existing scripts so you really need a version manager for things. Which is more complex setup and management of things. There are far too many different tools to help you with this and fetching dependencies which means if you work on lots of different projects by different people you have a hodge podge of diffing tools you need. It is a complete mess.


    Personally I hate python as a language, but you have picked some minor points that IMO dont really matter or that the other languages you use also suffer from. There are far better things to pick from that are far more annoying in the language.


  • I get this but, for what I know (I might be wrong tho), steam doesn’t get a cut from keys sold externally so they are technically selling them at better conditions elsewhere?

    It is a grey area. But I think the key point is that humble bundle at least don’t distribute the games in the same way as epic does. They typically offer steam keys which they get from steam probably with a different license or agreement with steam. Valve seems to not care that much about how the game is sold as long as you can activate it on steam. It cares more about people buying games on a competing platform cheaper then they can get a steam key for.

    I know that but that’s not really steam’s fault?

    Whos fault it is is irrelevant. If you have effective monopolistic power you are effectively a monopoly. If you abuse that power then that is bad. Does not really matter if you got there because you mostly do things people like or bully your way there. If you abuse the power that is still bad. And they could arguably be abusing that power against game devs by setting a fixed 30% fee with the devs not having much if any power to argue for less.


  • Not sure I’m understanding this but… how do you explain when we find in official retailers such as fanatical or humble same games at lower prices?

    At least for humble store, they essentially sell steam keys. Which at least complicates that argument. So it is not really a different distribution channel and the product is available on steam for that price. Just not on the Steam store.

    This I get, but couldn’t valve simply say: “Go to epic store if you want lower fees”?

    Steam have an effective monopoly here. Even if they have that because all the other platforms are shit. So the argument for just going to another store doesn’t really help as that just causes a massive loss in the market share of who you can sell your game to. Plus if you consider the other requirements of if you sell on steam you cannot make your game cheaper via a different distribution method means that you have to eat that feeling and cannot pass it on to customers. Which does not give game Devs much power to negotiate for a lower fee at all.



  • There has been some noise about the state of accessibility in Linux last year. Seems that things are improving and the Devs of major DEs are taking things more seriously. From a more recent blog post on the topic:

    Developers Are Rising to the Challenge

    Here’s the good news: I’ve talked to developers from GNOME, KDE, and Fedora.

    They get it. And they’re taking it seriously.

    GNOME’s Wayland session is now stable and usable with Orca. KDE is catching up — and has a legally blind developer leading accessibility improvements. COSMIC is building Wayland from scratch with accessibility and global hotkey support in mind. For once, accessibility isn’t just a postscript. It’s in the room where design happens.

    This transition is happening — but we’re not being ignored anymore.

    https://fireborn.mataroa.blog/blog/i-want-to-love-linux-it-doesnt-love-me-back-post-4-wayland-is-growing-up-and-now-we-dont-have-a-choice/

    The other posts in that series gives a good overview of previous things as well. Seems that author has been successful in raising awareness about the subject which hopefully will help improve things.


  • You cannot do that analysis with one sample. Why pick one day? That is an arbatary amount? Pick the 1 hour or minute that the CVE was released and you will find rust might be responsible for 100% of CVEs, Take a Week or year and that number drops dramatically. Pick the next day and that drops to 0%. You can select any % you want if you change what time period you are looking at.

    The fact that there has been one cve in 5 years of rust in the kernel is a bigger tell. There will be more rust CVEs, and each one is going to be big news as they happen so rarely.





  • Upgrades is any security or big fix as well. Those tend to be quite safe in point release distros. Upgrading to a new point release version is has all the same problems the rolling release had over the same period all bundle in one messy upgrade (which makes them a huge pain to deal with as they often compound). But between those, the patch upgrades tend to be quite smooth.

    I would say the over a longer time period rolling release break in bigger way less often. But they tend to have more but smaller breakages that are easy to trivial to fix.