Announcement

Collapse
No announcement yet.

DragonFlyBSD Developing DSynth As Synth Rewrite For Custom Package Building

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • DragonFlyBSD Developing DSynth As Synth Rewrite For Custom Package Building

    Phoronix: DragonFlyBSD Developing DSynth As Synth Rewrite For Custom Package Building

    Adding to another creation being worked on by DragonFlyBSD lead developer Matthew Dillon, DSynth is a C rewrite of the FreeBSD originating Synth program that serves as a custom package repository builder...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Nice! I'll have to check it out. Synth is the most powerful tool I've ever seen for building a local repo and keeping it up to date. Very cool.

    Comment


    • #3
      Originally posted by AndyChow View Post
      Nice! I'll have to check it out. Synth is the most powerful tool I've ever seen for building a local repo and keeping it up to date. Very cool.
      Yeah. It has been "must have it installed" for me too on both BSD's (synth was created by John Marino for both, DragonFly and FreeBSD).

      So, do I understand it correctly, it's rewrite becomes part of DragonFly's base?

      Comment


      • #4
        Originally posted by Lucretia
        "Let's rewrite a tool which is designed and works well, in a lesser language!" Well, this is a really stupid decision. I'm betting the C version will be less stable than the Ada version. This is typical NIH syndrome.
        If he plans on it becoming actual part of the operating system, then it's not. Then it means preventing problems before they can occur. At some point in the future synth may break, already you need 2 different GCC versions, one for system itself (GCC8), other for synth (GCC6-Ada).
        Last edited by aht0; 22 August 2019, 06:45 PM.

        Comment


        • #5
          Lol. Just LOL. C used in most demanding applications, like realtime control of dangerous processes on transport, industrial and somesuch. C firmwares keep last line of defence in industrial systems (microcontrollers). Fail that - and things would blow up, sometimes literally. Say, modern inverter/switched power supply/engine control unit could be nothing more than MCU hooked up to power electronics, doing things most straightforward way - MCU just toggles whatever GPIO or peripherals in real time to do what device meant to do. Replacing ton of "simple logic" circuits and so on.

          Needless to say, this puts ultimate demands - and C can do it. Though dev surely have to take specifics of their task into account and WHOLE DEVELOPMENT PROCESS have to match the task. Merely selecting another language would hardly change things much if development processes happen wrong ways. Let's say "most expensive software bug ever" that crashed Arian rocket happened in software written in Ada. I guess it can serve as fairly good proof of my views on software reliability vs language?

          Actually I would not trust ability of devs who thinks language, framework, lib or other silver bullet can magically save them from responsibility of careful coding and full understanding of processes to deliver reliable software. That's one of worst anti-patterns of modern software development I know. Relying on opaque tech (runtime, lib, language, etc) you don't even understand "end to end" (from source construct to what machine code would really do and also handling edge cases like errors) is very good way to ... jeopardize software reliability.

          p.s. btw, DFBSD is nearly most sane thing out of all BSDs - neither plagued by NIH too much, nor inclined on purely theoretic constructions, yet got some taste of doing things right. Say, they managed to develop surprisingly sane looking HammerFS. Other BSDs either rely on ZFS enterprise monstrosity from sun or got really ancient fileystems. DFBSD is the only one BSD that dared to try something better than that. Guess if we imagine there was no Linux, I can imagine I've been using that one eventually.
          Last edited by SystemCrasher; 25 August 2019, 11:21 AM.

          Comment


          • #6
            Originally posted by Lucretia
            The fact that you are talking about preventing possible problems with Ada and thinking there won't be with C is a joke, if there's going to be problems it's going to be with C, not Ada. I've been using GNAT for over 14 years and well aware of what it can and cannot do, I've written code which has been mainly tested on Linux which just compiles on other platforms (Windows, Mac) without problems and without porting, just GPR file modifications, I seriously doubt that Synth cannot be built with a later GCC/GNAT.
            Problem 1) DragonFly is written in C. synth is written in Ada. If you want it to become your system component, shouldn't it be written in the same language as the rest of the OS?
            Problem 2) John R. Marino has new projects at hand (Ravenports for example). So, makes sense to rewrite it. so it will be kept up to date with the rest of the system, instead of having 3rd party app people would have to install separately - which also may run out of order simply because underlying OS changes some way of doing things.

            Personally, I also disliked trashing my SSD's compiling two different compilers to use it in the first place (I am not using default binaries because of custom /etc/make.conf - you don't want to mix and match default and custom packages)

            Comment


            • #7
              Originally posted by Lucretia
              Doesn't matter if they're different languages.
              And again, if you ```--enable-languages=c,c++,ada``` when building GCC, where's the problem? Oh, it's written in Ada, that's the problem. If it was written in C++ or Rust you wouldn't be defending this.
              And if it wsa written in C++ or Rust, that'd be another compiler "trashing your SSD's" which is also the biggest pile of bullshit I've ever read. Again, an Ada compiler can be a default package, only you myopic people cannot see this.
              First of all, I don't have anything particular against Ada, so rein in your butthurtedness.

              dsynth is being developed in C, same as used for the rest of the operating system.

              Biggest pile of bs? Do a system uprade, containing buildworld, buildkernel, gcc6-aux (what synth requires), gcc8 (for OS) and llvm80 (required by many packages) + re-building installed packages and see how many gigabytes of data gets written to your storage device(s). When you run system that gets upgraded from source on a regular basis, then that wear-and-tear adds up.
              Might use default packages but for a number of, default options are not what I need, so I have to build the packages using synth regardless - I am not going to mix-and-match 'default-option-packages' and custom's - that's road to breakage. I am all for eliminating one compiler from that list. There are some other packages that also take lots of resources building but building compilers is just agonizing to watch from my pov.

              If devs decided they do not want to change/add to package options in 'dports' (like adding Ada support to GCC8), then so be it. It's theirs to decide because they are the worker-bees, I am just a user.
              Less custom changes generally means faster sync against FreeBSD ports collection DragonFly's dports feeds off from. Tiny change maybe but once you go that road, it tends to adds up. There's already thousands of packages needing 'massage' to get them work on DragonFly.

              Comment


              • #8
                Originally posted by Lucretia
                There's always some dickhead who thinks they know about the Ariane V, I'm 99% certain, you're another who's only been told about what happened with Ariane without actually being told what was responsible. I'll spell it out for you, management decided to use a package from the previous rocket which wasn't tested with the Ariane V and it caused an overflow. If you bothered to search for it you'd be able to read all about it and the reasons it failed, it was nothing to do with the software, it was management cost cutting. But then you don't care about that.
                Oh, I would answer you your language. So be it. There're some dickheads who pretend they know how to do software development right - without extensive practice of doing that or evaluating failures, outcomes and root causes. Eventually those dickheads start to suffer badly from weird form of tunnel vision, naively believing that just one approach, language, paradigm, tool, runtime or whatever silver bullet they believe would magically solve all software development problems, once and for all. Somehow, as one who actually took part in software development, large and small, I can just laugh on such a bizarre level of naiveness of some persons.

                Furthermore, such a navie beliefs lead to funny fails, where persons suffering from tunnel vision fail to consider other failure modes. Often quite obvious ones. Eventually, it leads to hilarious outcomes, Arian being a very decent showcase. Look, there are many ways to fail, buffer overruns and memory management aren't worst of these, and actually, as of now there're decent instrumentations to deal with it and if one really needs ultimate reliability ... one can get it by just avoiding these parts entirely. Say, MISRA C specs would address it a lot. Oh sure, it mostly brings us down to "static allocation" where we don't "allocate" and "release" stuff at all - preallocating everything we need at start, and being sure resources always available at run time when we need them. Sure, this way we can't reuse memory, oversell and overcommit - but on other hand it good for reliability.

                I wouldn't trust anyone who had to constantly keep remembering to check things and this is something you have to do with something as basic and primitive as C.
                There is good saying: "the most dangerous time is when you feel yourself safe". So speaking for myself, when I need something to be really reliable, I prefer it to be as simple as feasible - in both HW and SW. But not simpler than that. So "primitive" is actually good thing for critical system, it imply there're few well-known failure modes that are easy to track - and avoid. On other hand, evaluating all possible interactions in complicated/high/level/overfeatured/overengineered/too abstract system could be a bitch. I'd say that when I code something with demands for reliability I have to think like "whole world is against me and my program". C merely keeps me in shape for that, preventing me from being careless and ignorant. At which point I can also evaluate far more arcane hardware faults, for example. Say, if something should be really reliable, one can consider even some truly bizarre faults, like program counter runaway (and there is nothing wrong if power surge or space particle eventually causes it in HW). It breaks abstractions to nowhere - now CPU jumps to arbitrary part of code and trying to execute it. What now? Specific firmware design can catch even this - but it takes degree of paranoia, good overall view of system and ... defensive thinking. Something high level nuts tend to lack.

                Say, with C I can have very good estimate of "how many microseconds my firmware would take to respond that critical input at absolutely worst?". I can compute it down to low microseconds if not nanoseconds if that really matters - going down after hardware operations cycle by cycle. High-levell nuts usually do not have this level of system view at all, or shout weird abstract answers, NOT backed by knowledge of their hardware or instruction stream and evaluation of "what the worst it can do".

                People tend to forget those things especially under pressure. Saying people don't know how things work underneath is stupid, arrogant and ignorant and people who know Ada do know what is going on underneath.
                That's why it is important to have proper development practices in first place. Defencive thinkind on dev side - so dev always considers worst possible outcomes rather than being in safe comfort of ignorance and black-box magic. Running some automatic checkers, code reviews, conformance checks, extensive tests, sane policies and so on - to name few obvious things. And no, just using Ada doesn't magically brings anyone here. Arian clearly reminds us that.

                So when I see something like $subj, I would trust judgement of people behind it - on overall system layer. Nor would I expect their software to be faulty or troublesome. I would expect if from noisy hipsters boasting about go or rust, wannabe-rapid developers who think saving pennies on coding FTW, javascripters who are lazy to even annotate data types, ending up with truly bizarre faults and so on. Interestingly I've thought Ada ppl are more level-headed but it seems it isn't a case...

                I'm well aware of DFly and Matt, I've been well aware of him since AmigaOS days.
                That was generic remark to everyone. I've been just too lazy to start whole new post to put that.

                Comment


                • #9
                  Originally posted by Lucretia
                  Doesn't matter if they're different languages.
                  Opensource is about ability to change source. I dare to say learning Ada for just one tool in system sounds waaaaaay too far off the track for me - at which point I'm going to dislike such tool in my system. So speaking for myself I really prefer my "system core" and its essential parts in C. Well, I don't think someone would manage to write Linux (or even NetBSD) kernel equivalent in Ada... so it's not like we're going to get rid of C in foreseeable future. Failing to learn C imply you can't dig in system internals and change these, so no opensource benefits for you, huh. It also usually implies person doesn't understands inner hardware working, at which point I would be highly skeptical about their reliability mumblings and somesuch. As they likely would fail to evaluate ton of funny failure modes, etc. Say, Linux system engineers must know plenty of stuff about memory locking, overcommits and so on if they ever care for reliability for the real. How many high level devs can even remember these words or knows how their (cr)app really interacts with OS and how it could fail, etc? So high level apps tend to fail in hilarious ways if things go imperfect, that's just my observarion on how things work. Proper error handling, epecially in sane ways is boring, tedious, and even worse than memory management or something. Fail that and get very fragile app that suddenly does bizarre things on slight imperfections like e.g. network down, memory pressure or HDD suddenly returning garbage in one data files.

                  Furthermore, looking on amount of, say, tests, analisys, testers, related infrastructure and so on for e.g. Linux kernel I dare to say others would struggle to achieve same level of quality at same complexity and feature levels. Regardless of language. Thousands of eyes of different persons with diverse views looking into code eventually manage to spot failures others even failed to imagine. Reasonable project layering and splitting is another important topic, that does not happens on its own, regardless of language. Somehow C allows to split to mostly-independent subparts just like any other language. Not without its historic quirks, but it works overall.

                  And again, if you ```--enable-languages=c,c++,ada``` when building GCC, where's the problem? Oh, it's written in Ada, that's the problem. If it was written in C++ or Rust you wouldn't be defending this.
                  I'm not aht0, and I stick to more pragmatic approach: if I don't like something, I eventually go, put my (maybe not so smart) nose inside the code and eventually change it to behave the way I like it. And, erm, to change tool written in Ada it takes a bit more than just --enable-something=. I have to learn some rather esoteric language, rarely used anywhere else, just to change one tool. Uh, sure, it puts "exotic" languages at disadvantage, but we have to live with the fact human brain resources are finite.

                  And if it wsa written in C++ or Rust, that'd be another compiler "trashing your SSD's" which is also the biggest pile of bullshit I've ever read. Again, an Ada compiler can be a default package, only you myopic people cannot see this.
                  While it sounds debatable, I have few funny observations. Say, when gnome fucks rewrote some lib in Rust, its code size skyrocketed, increasing by several more megabytes. Should it happen to many libs, there is clearly room for "thrashing". Oh, sure, you can find horrible monsters even in C libs, say, libxml or glib to name a few. However, in C spitting out megabytes of code is extraordinary achievement rather than norm. Much less so in C++ and even less so in Rust, Go, etc... and eventually we end up with electron (cr)apps taking 2Gb just to start up. C is good in this regard as it makes coding huge shit inconvenient. So C coders would think twice before going bloatware. That's what makes their programs pleasant to use - these tend to be light, fast, and more or less written by sane devs who had at least some idea what they do and why. Without being obsessed to rapidly spit out some "enterprise-grade" crap at the cost of everything else, the true plague of corporate development and hipsters-driven stuff.

                  I dare to say unix way wouldn't feel cool if it would be implemented like that. I dare to think unix way's strongest point is ability to connect relatively simple and fast programs into "chains". It makes system level automation, ad-hoc tasks solutions and so on a breeze (and uhm, Linux inherited that best part, fortunately).
                  Last edited by SystemCrasher; 11 September 2019, 02:07 AM.

                  Comment

                  Working...
                  X