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...

    http://www.phoronix.com/scan.php?pag...DSynth-Builder

  • #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
        "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.
        Last edited by Lucretia; 08-22-2019, 07:05 AM.

        Comment


        • #5
          Originally posted by Lucretia View Post
          "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; 08-22-2019, 06:45 PM.

          Comment


          • #6
            Originally posted by aht0 View Post

            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).
            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.

            Comment


            • #7
              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; 08-25-2019, 11:21 AM.

              Comment


              • #8
                Originally posted by Lucretia View Post
                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


                • #9
                  Originally posted by SystemCrasher View Post
                  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?
                  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.

                  Originally posted by SystemCrasher View Post
                  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.
                  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. 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.

                  Originally posted by SystemCrasher View Post
                  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.
                  I'm well aware of DFly and Matt, I've been well aware of him since AmigaOS days.

                  Comment


                  • #10
                    Originally posted by aht0 View Post

                    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?
                    Doesn't matter if they're different languages.

                    Originally posted by aht0 View Post
                    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.
                    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.

                    Originally posted by aht0 View Post
                    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)
                    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.
                    Last edited by Lucretia; 08-25-2019, 07:41 PM.

                    Comment

                    Working...
                    X