The real deal y0

  • 0 Posts
  • 76 Comments
Joined 1 year ago
cake
Cake day: July 16th, 2023

help-circle
  • As a software developer i know what iterative development means, its in our blood and brains ( or at least it should be ). Simulations can indeed only get you so far, and i agree sometimes you have to make things and take a plunge. However, and i would like to be really wrong here so correct me if im wrong, but other companies like nasa, do not just shoot shit up in space and hope for the best. They arent allowed to do so for a reason. They test and calculate everything very rigoursly to make sure itll hold up as expected. From thruster power, resistance to continues extreme heat from reentry, …
    All of that they do here, on earth, before shooting anything up into space. Otherwise things like the rover on mars would have needed like 20 tries instead of 2.

    These are things that looks like spacex is just throwing out the window.
    To take it back to software development, they are doing an iterative development ( which is very good for what they are doing! ) but their testing before production/release of software is so basic theyll just see how it responds out there. Thats a huge nono to me if youre going to end up crashing all those rockets in the sea killing a shit ton of nature in the process. Sometimes the means dont justify the costs to me, and this is one of them. Yes, the booster catching was nice to see ( eventhough it nearly ended badly ) and its idea is very good and needed, but the way to get there is…messy.


  • Specially this. How space x handles failures is a very hard nono in my book. “But we test in the field” is what space x says, and as a software developer its like saying “we test in production”.
    Yes youll get something use able faster, but its way way more costly in the long run and is nasty in between.
    My arse they cant test this stuff on earth. We have simulations, models, calculations, test, everything. Yes, things can and will sometimes still fail when going in production ( in flight ) but you want to lower the risk of it failing cause its costly as fuck.

    They dont seem to care though.

    Also, im not saying what they are building towards is bad, it really really isnt, but their methods is… Bad


  • DacoTaco@lemmy.worldtoOpen Source@lemmy.ml***
    link
    fedilink
    arrow-up
    4
    arrow-down
    2
    ·
    edit-2
    2 months ago

    Their source code repo contains a copy of libogc for wii/gc builds because they were annoyed at us. And i do mean a copy. Not a reference, or a sub-module, a full on copy that they build before building the wii/gc executable.

    Their own issue, as long as we dont get reports of their broken shit…

    Then there are the multiple times they cloned emu repos and butchered them into cores. Or the fact they force the core interface on emulators making them bad.

    Retroarch is a nice project from a far, but the closer you look, the more you see huge ass cracks in the project, held down with duct-tape



  • Not saying youre wrong, but you took the wrong project as an example hehe.
    Visual code is not open source. Its core is, but visual code isnt. The difference is what visual code ships with, on top of its core.
    Its like saying chrome == chromium ( it isnt ).

    Visual code comes with a lot of features, addins and other stuff that isnt in the core.
    .net debugger for example, is not found in vscodium ( build of the vscode core ). And there is more stuff i cant think of now but have come across. Source: been using vscodium for a few months instead of vscode



  • Thats just dual booting. That wont work with the law if the contract says anything created using company hardware is theirs.
    And yes, some companies need to give you a green light to work on projects in your free time, because they might have a team doing similar things somewhere, it might compete in something they would like to do in the future or like you said, might use company know how which is a huge nono. Its bs imo, but those clauses and rules are found in some employment agreements.
    Remember, always read your employment agreements!



  • And not every team is allowed to do that.
    Also, youre telling somebody who has worked with big companies not allowing it in their employer contract that he is lying? Riiiight…
    A lot of google devs also are not allowed to do any linux work outside of work without explicit permissions because of all the internal docs, teams and other work being done on linux from within google. Development rights is an absolute mess, legally.
    I usually dont care and do what is right, despite what my emploter contract says, but i have gotten in trouble for it


  • I agree they should have sent a patch to the grub source, but keep in mind big software companies like microsoft, Verizon, … do not normally allow their product teams to send a patch or PR to open source projects. This is because in their contract it states that all code written on and during company times is owned by the company. This means that it is impossible for them to make a patch or PR because it would conflict with the projects licence and fact its open source.
    This changes when the team explicitly works on the foss product/project like the ms wsl team or the team working on linux supporting azure hardware, but that is an exception. I do not believe the microsoft kernel/bootloader team is allowed to send patches to grub.

    Its a terrible thing, and it shouldnt be, but thats the fact of the world atm.







  • What im about to say applies to belgium, and i dont know about other countries or companies or how it works if a company from another country has a base in belgium, so take everything i say with a pinch of salt.
    SO
    In belgium every company with more than x amount of employees ( i think its either 50 or 100 ) must have a worker council meeting every month and have worker council member votings every few years, to select what employee will join said meetings with a select few people of the heads of the company. The members are people who have joined a union ( which is just being registered, has nothing to do with your job and which union depends on the job and your political views. Each union is large enough to cause mayhem and force talks ) and have put themselves forward to be in those meetings.
    After said voting, the representatives are selected and join the meetings.
    While the representative is selected him or her can not be easily fired or laid off. While they are registered at a union they also can not be fired without a valid reason, as that would get the company investigated.

    So overall here what union doesnt mean that much, but the process is more important.

    I would also like to point out that i love this whole thing, even if ive worked with a complete asshat that was the workers representative and seriously needed to be fired because he did his actual job (handyman) terribly. The fact he was in those meetings meant the workers were represented and im sure he did that part right as he kept being voted for.



  • Thats interresting, thanks! Stuff for me to look into!
    I also think halfway through the conversation i might have given the impression i was talking about pointers, while it was not my intention to do so. That said, the readonly/mutable reference thing is very interresting!
    Ill look into what rust does/has that is like the following psuedocode :

    DataBaseUser variable1 = GetDataBaseUser(20);
    userService.Users.Add(variable1);
    variable1 = null; // or free?
    [end of function scope here, reference to heap now in list ]



  • Thanks for the response. Ive heard of rust’s compiler being very smart and checking a ton of stuff. Its good thing it does, but i feel like there are things that can cause this issues rust cant catch. Cant put my finger on it.
    What would rust do if you have a class A create something on the heap, and it passes this variable ( by ref ? ) to class B, which saves the value into a private variable in class B. Class A gets out of scope, and would be cleaned up. What it put on the heap would be cleaned up, but class B still has a reference(?) to the value on the heap, no? How would rust handle such a case?