Perhaps the developers want to take a look at this distribution.It is reported that is written in a `purely functional package management' and tries to be a highly safe OS, where `upgrading a system is as reliable as reinstalling from scratch'. http://nixos.org/nixos/
Because the files of a new configuration don’t overwrite old ones, you can (atomically) roll back to a previous configuration. For instance, if after a nixos-rebuild switch you discover that you don’t like the new configuration, you can just go back
It can be an inspiration for a new version of pacman rewritten in haskell? Also Don Stewart's talk about 'Scripting with Types' might inspire someone too (BTW since he started arch-haskell I think he is a Arch user): http://donsbot.files.wordpress.com/2009/01/semicolon.pdf
On Mon, 21 Nov 2011 11:23:58 -0800 Bernardo Barros <bernardobarros2@gmail.com> wrote:
Perhaps the developers want to take a look at this distribution.It is reported that is written in a `purely functional package management' and tries to be a highly safe OS, where `upgrading a system is as reliable as reinstalling from scratch'.
Because the files of a new configuration don’t overwrite old ones, you can (atomically) roll back to a previous configuration. For instance, if after a nixos-rebuild switch you discover that you don’t like the new configuration, you can just go back
It can be an inspiration for a new version of pacman rewritten in haskell? Also Don Stewart's talk about 'Scripting with Types' might inspire someone too (BTW since he started arch-haskell I think he is a Arch user):
Well I'm just a TU but I guess most people here are always pleasured for people bringing up their ideas, when they want to realize them by themselves. Seriously, it's probably meant like this but your mail reads like a "Hey why don't you learn $INSERT_LANG_HERE and rewrite your whole system." I've not participated in pacman development myself so I guess I should stfu myself, but for me this proposal just reads like a kick into the faces of Allan, Dan and all the other people who did so. Kind Regards Thorsten -- Jabber: atsutane@freethoughts.de Blog: http://atsutane.freethoughts.de/ Key: 295AFBF4 FP: 39F8 80E5 0E49 A4D1 1341 E8F9 39E4 F17F 295A FBF4
On Mon, Nov 21, 2011 at 11:40 AM, Thorsten Töpper <atsutane@freethoughts.de> wrote:
Seriously, it's probably meant like this but your mail reads like a "Hey why don't you learn $INSERT_LANG_HERE and rewrite your whole system."
Hello Thorsten, no, you got it wrong. It's about ideas not languages. I think it makes sense in a rolling release OS like Arch. Ideas like for example pacman --rollback Would be possible then
Those guys wrote their ideas down here for those interested: http://www.st.ewi.tudelft.nl/~dolstra/pubs/nixos-jfp-final.pdf
Bernardo Barros (2011-11-21 11:43):
On Mon, Nov 21, 2011 at 11:40 AM, Thorsten Töpper <atsutane@freethoughts.de> wrote:
Seriously, it's probably meant like this but your mail reads like a "Hey why don't you learn $INSERT_LANG_HERE and rewrite your whole system."
Hello Thorsten, no, you got it wrong.
It's about ideas not languages. I think it makes sense in a rolling release OS like Arch.
Ideas like for example
pacman --rollback
Would be possible then
"Rolling release" and "rollback" don't go together. You want to move forward (upgrade), not back, or you don't want a rolling release. Suggestion: read point 1. at https://wiki.archlinux.org/index.php/The_Arch_Way and look at nixos again.
Am 21.11.2011 20:43, schrieb Bernardo Barros:
On Mon, Nov 21, 2011 at 11:40 AM, Thorsten Töpper <atsutane@freethoughts.de> wrote:
Seriously, it's probably meant like this but your mail reads like a "Hey why don't you learn $INSERT_LANG_HERE and rewrite your whole system."
Hello Thorsten, no, you got it wrong.
It's about ideas not languages. I think it makes sense in a rolling release OS like Arch.
Ideas like for example
pacman --rollback
Would be possible then
We have an old bug reprot about this. See my comment at https://bugs.archlinux.org/task/8585#comment47567 With btrfs this might be possible to implement in a clean and sane way. And as I said back then: This feature does not really belong in a package manager; even though ti could trigger snapshot creation etc. -- Pierre Schmitz, http://pierre-schmitz.com
On Mon, Nov 21, 2011 at 8:58 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
Am 21.11.2011 20:43, schrieb Bernardo Barros:
On Mon, Nov 21, 2011 at 11:40 AM, Thorsten Töpper <atsutane@freethoughts.de> wrote:
Seriously, it's probably meant like this but your mail reads like a "Hey why don't you learn $INSERT_LANG_HERE and rewrite your whole system."
Hello Thorsten, no, you got it wrong.
It's about ideas not languages. I think it makes sense in a rolling release OS like Arch.
Ideas like for example
pacman --rollback
Would be possible then
We have an old bug reprot about this. See my comment at https://bugs.archlinux.org/task/8585#comment47567
With btrfs this might be possible to implement in a clean and sane way. And as I said back then: This feature does not really belong in a package manager; even though ti could trigger snapshot creation etc.
-- Pierre Schmitz, http://pierre-schmitz.com
+1 I prefer a general method of rolling back changes, not a package-focused one. I think you can use ARM and 'pacman -Suu' e.g. http://arm.konnichi.com/2011/11/20/
On (11/21/11 11:43), Bernardo Barros wrote: -~> On Mon, Nov 21, 2011 at 11:40 AM, Thorsten Töpper -~> <atsutane@freethoughts.de> wrote: -~> > Seriously, it's probably meant like this but your mail reads like a -~> > "Hey why don't you learn $INSERT_LANG_HERE and rewrite your whole -~> > system." -~> > -~> -~> Hello Thorsten, no, you got it wrong. -~> -~> It's about ideas not languages. I think it makes sense in a rolling -~> release OS like Arch. -~> -~> Ideas like for example -~> -~> pacman --rollback -~> -~> Would be possible then And the idea would be... dpkg-reconfigure -- reinventing the wheel is fun :) Seriously though, your title is completely misleading. -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
dpkg-reconfigure ? No.. it's not that at all. In fact pacman already have some of those ideas, it tries to be safe when it keeps old package in /var/cache/pacman/pkg, but Nix goes further and tries to make sense of all those changes in the system. I just see some other ideas that could be inspiring futures versions of pacman, that all: http://www.st.ewi.tudelft.nl/~dolstra/pubs/eupfcdm-cbse2005-final.pdf
On (11/21/11 12:17), Bernardo Barros wrote: -~> dpkg-reconfigure ? No.. it's not that at all. -~> -~> In fact pacman already have some of those ideas, -~> it tries to be safe when it keeps old package in /var/cache/pacman/pkg, -~> but Nix goes further and tries to make sense of all those changes in the system. -~> -~> I just see some other ideas that could be inspiring futures versions -~> of pacman, that all: -~> -~> http://www.st.ewi.tudelft.nl/~dolstra/pubs/eupfcdm-cbse2005-final.pdf Well, it deals with configuration problems after an update... The point of this paper is basically to automatically test the updated software version in a VM. The only new concept here is "automatically", perhaps. I can't imagine anyone who would do a major server/kernel upgrade w/o trying it in a testbox beforehand. Updates are supposed to be dangerous, that is exactly why we have SLES/RHEL/Debian with lots of backports. For example, you update subversion to a newer version, which has some incompatibility with older DBs. All the NixOS tests will be fine, but suddenly half of your clients can't checkout. If the system is important, I wouldn't rely some dumb software and do all tests myself. -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
Yes, But also the idea of reproducible system configurations is also interesting. You could say, hey, this configuration will work for this because it was tested in such and such a way. And after a complex upgrade you could roll-back to a particular configuration that happened to work very well for you in a recent past. I think that's good!
On Mon, Nov 21, 2011 at 2:03 PM, Bernardo Barros <bernardobarros2@gmail.com> wrote:
And after a complex upgrade you could roll-back to a particular configuration that happened to work very well for you in a recent past.
They do it from grub even if the kernel wasn't update. I agree that's odd, but this could be done differently too.
The 21/11/11, Thorsten Töpper wrote:
Seriously, it's probably meant like this but your mail reads like a "Hey why don't you learn $INSERT_LANG_HERE and rewrite your whole system."
I've not participated in pacman development myself so I guess I should stfu myself, but for me this proposal just reads like a kick into the faces of Allan, Dan and all the other people who did so.
I don't think, so. Or nothing could be discussed because some others did another choice some time ago. OP raised one or two benefits of Haskell over shell scripting. He is right even if it's somewhat partial: many of high-level languages have very good advantages over shell scripting. I do think pacman could be much better if rewritten in one of these languages. -- Nicolas Sebrecht
On Tue, Nov 22, 2011 at 10:50 AM, Nicolas Sebrecht <nsebrecht@piing.fr> wrote:
The 21/11/11, Thorsten Töpper wrote:
Seriously, it's probably meant like this but your mail reads like a "Hey why don't you learn $INSERT_LANG_HERE and rewrite your whole system."
I've not participated in pacman development myself so I guess I should stfu myself, but for me this proposal just reads like a kick into the faces of Allan, Dan and all the other people who did so.
I don't think, so. Or nothing could be discussed because some others did another choice some time ago.
OP raised one or two benefits of Haskell over shell scripting. He is right even if it's somewhat partial: many of high-level languages have very good advantages over shell scripting. I do think pacman could be much better if rewritten in one of these languages.
-- Nicolas Sebrecht
Isn't pacman written in C?
The 22/11/11, Karol Blazewicz wrote:
On Tue, Nov 22, 2011 at 10:50 AM, Nicolas Sebrecht <nsebrecht@piing.fr> wrote:
OP raised one or two benefits of Haskell over shell scripting. He is right even if it's somewhat partial: many of high-level languages have very good advantages over shell scripting. I do think pacman could be much better if rewritten in one of these languages.
Isn't pacman written in C?
Yep, sorry. s/shell scripting/low-level progrmming languages like C/g :-) -- Nicolas Sebrecht
On 22/11/11 12:02, Nicolas Sebrecht wrote:
The 22/11/11, Karol Blazewicz wrote:
On Tue, Nov 22, 2011 at 10:50 AM, Nicolas Sebrecht<nsebrecht@piing.fr> wrote:
OP raised one or two benefits of Haskell over shell scripting. He is right even if it's somewhat partial: many of high-level languages have very good advantages over shell scripting. I do think pacman could be much better if rewritten in one of these languages.
Isn't pacman written in C?
Yep, sorry.
s/shell scripting/low-level progrmming languages like C/g
:-)
Pacman devs appreciatie patches, or in case you want to port pacman to haskell, just do it. ( look for example at how the 64 bit port became official ) as wise phrik tells me: 11:05 jelly1 | !toofishes 11:05 phrik | patches welcome -- Jelle van der Waa
On Tue, Nov 22, 2011 at 12:06 PM, Jelle van der Waa <jelle@vdwaa.nl> wrote:
On 22/11/11 12:02, Nicolas Sebrecht wrote:
The 22/11/11, Karol Blazewicz wrote:
On Tue, Nov 22, 2011 at 10:50 AM, Nicolas Sebrecht<nsebrecht@piing.fr> wrote:
OP raised one or two benefits of Haskell over shell scripting. He is right even if it's somewhat partial: many of high-level languages have very good advantages over shell scripting. I do think pacman could be much better if rewritten in one of these languages.
Isn't pacman written in C?
Yep, sorry.
s/shell scripting/low-level progrmming languages like C/g
:-)
Pacman devs appreciatie patches, or in case you want to port pacman to haskell, just do it. ( look for example at how the 64 bit port became official )
as wise phrik tells me:
11:05 jelly1 | !toofishes 11:05 phrik | patches welcome
-- Jelle van der Waa
In case you (ML subscribers) didn't know / forgot, phrik is an IRC bot :-) https://wiki.archlinux.org/index.php/IRC_Channel#.23archlinux_rules
On Tue, Nov 22, 2011 at 12:02, Nicolas Sebrecht <nsebrecht@piing.fr> wrote:
The 22/11/11, Karol Blazewicz wrote:
On Tue, Nov 22, 2011 at 10:50 AM, Nicolas Sebrecht <nsebrecht@piing.fr> wrote:
OP raised one or two benefits of Haskell over shell scripting. He is right even if it's somewhat partial: many of high-level languages have very good advantages over shell scripting. I do think pacman could be much better if rewritten in one of these languages.
Isn't pacman written in C?
Yep, sorry.
s/shell scripting/low-level progrmming languages like C/g
:-)
I am somewhat allergic to the kind of statements you make. It sounds like you are alluding to Haskell (and other hi-level languages, whatever _that_ means) as some sort of magic pixie dust that can be taken out in order to spray good-ness on a software project. There are dozens of other things to consider. In this particular case these are the most pertinent IMNSHO: - Many of these languages improve the ability to reason about the behaviour of the program. This _can_ improve quality. HOWEVER, pacman doesn't strike as a tool that suffers from bad quality, there seems to be a development team that fully understand the crucial role that pacman plays in Arch and they behave accordingly in relation to rolling out updates. - Many of these languages allow for quicker development; by raising the abstraction level it's possible to express more complex ideas in fewer lines of code and given that the lines/hour written by a developer is fairly static across languages it leads to quicker development. HOWEVER, pacman doesn't suffer from slow development, there are new releases with new features fairly frequently (probably as frequently as the community can stand them). - Finally with each language comes a pool of possible contributors, the group of people who already know, or are willing to learn the language. For C this pool is huge, for most of these hi-level languages not so. So my conclusion is that when you say "I do think pacman could much better if rewritten in one of these languages", then I say that you most likely are completely wrong. The more likely effect of rewriting pacman in one of these languages is that the current development team would disperse, there wouldn't be as large a pool of programmers to recruit from to replace them, and in the end pacman would turn out to be worse. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus
On Tuesday 22 Nov 2011 12:20:25 Magnus Therning wrote:
- Many of these languages improve the ability to reason about the behaviour of the program. This _can_ improve quality. HOWEVER, pacman doesn't strike as a tool that suffers from bad quality, there seems to be a development team that fully understand the crucial role that pacman plays in Arch and they behave accordingly in relation to rolling out updates.
We should also bear in mind that most of what Pacman does is speed-critical database-like operations. I'm a huge Ruby fan, but I'm happy to admit that it's crazy slow compared to C. It simply doesn't make sense to rewrite it in another language; C is just about as fast as you can get. However, it *does* make sense to move most of the performance-critical sections into a shared library, for which bindings can be written for other languages. That way, you can quickly play with some concepts and write tools in easier languages on top on the library. That's actually pretty much what has been done already. Paul
On 22 November 2011 11:20, Magnus Therning <magnus@therning.org> wrote:
So my conclusion is that when you say "I do think pacman could much better if rewritten in one of these languages", then I say that you most likely are completely wrong. The more likely effect of rewriting pacman in one of these languages is that the current development team would disperse, there wouldn't be as large a pool of programmers to recruit from to replace them, and in the end pacman would turn out to be worse.
Spot on. I agree 100% with this, well said. Clive -- Infinity: A concept for those who cannot comprehend the big picture. () Arch Linux - For movers and shakers. ()
The 22/11/11, Magnus Therning wrote:
I am somewhat allergic to the kind of statements you make.
Don't be. We are only _discussing_ the advantages/disadvantages of the current language, aren't we? Please, don't be allergic from talking.
It sounds like you are alluding to Haskell (and other hi-level languages, whatever _that_ means) as some sort of magic pixie dust that can be taken out in order to spray good-ness on a software project. There are dozens of other things to consider. In this particular case these are the most pertinent IMNSHO:
- Many of these languages improve the ability to reason about the behaviour of the program. This _can_ improve quality. HOWEVER, pacman doesn't strike as a tool that suffers from bad quality,
But it's missing advanced features. OP raised rollbacks, I'd rather talk about simultaneous/concurrency pacman calls and mutli-threading to handle packages installation where applicable (handling pools of per-package fetch, uncompress & install processes), for example. Or even a _three-way merge_ tool for configuration files (think of dispatch-conf), /etc snapshoting, check for conflicting path namespaces of files over packages at installation time (not sure this check is already done for every file), or whatever smart thing could be implemented. I'm not saying all of this should be implemented. At least, allowing wide contributions (from the technical POV, with a more simple language) permits nicer discussions and by the end, interesting features to be implemented.
there seems to be a development team that fully understand the crucial role that pacman plays in Arch and they behave accordingly in relation to rolling out updates.
- Many of these languages allow for quicker development; by raising the abstraction level it's possible to express more complex ideas in fewer lines of code and given that the lines/hour written by a developer is fairly static across languages it leads to quicker development. HOWEVER, pacman doesn't suffer from slow development, there are new releases with new features fairly frequently (probably as frequently as the community can stand them).
According to what _you_ expect from a package manager to do.
- Finally with each language comes a pool of possible contributors, the group of people who already know, or are willing to learn the language. For C this pool is huge, for most of these hi-level languages not so.
So my conclusion is that when you say "I do think pacman could much better if rewritten in one of these languages", then I say that you most likely are completely wrong. The more likely effect of rewriting pacman in one of these languages is that the current development team would disperse, there wouldn't be as large a pool of programmers to recruit from to replace them, and in the end pacman would turn out to be worse.
Oh, come on. You're kidding me, right? Did anyone talked about spreading in the wild the current team? -- Nicolas Sebrecht
On Tue, Nov 22, 2011 at 13:02, Nicolas Sebrecht <nsebrecht@piing.fr> wrote:
The 22/11/11, Magnus Therning wrote:
I am somewhat allergic to the kind of statements you make.
Don't be. We are only _discussing_ the advantages/disadvantages of the current language, aren't we?
Please, don't be allergic from talking.
I'm allergic to often-repeated statements that are born out of naivite ;)
It sounds like you are alluding to Haskell (and other hi-level languages, whatever _that_ means) as some sort of magic pixie dust that can be taken out in order to spray good-ness on a software project. There are dozens of other things to consider. In this particular case these are the most pertinent IMNSHO:
- Many of these languages improve the ability to reason about the behaviour of the program. This _can_ improve quality. HOWEVER, pacman doesn't strike as a tool that suffers from bad quality,
But it's missing advanced features.
OP raised rollbacks, I'd rather talk about simultaneous/concurrency pacman calls and mutli-threading to handle packages installation where applicable (handling pools of per-package fetch, uncompress & install processes), for example. Or even a _three-way merge_ tool for configuration files (think of dispatch-conf), /etc snapshoting, check for conflicting path namespaces of files over packages at installation time (not sure this check is already done for every file), or whatever smart thing could be implemented.
I'm not saying all of this should be implemented. At least, allowing wide contributions (from the technical POV, with a more simple language) permits nicer discussions and by the end, interesting features to be implemented.
"Simple language"? Even if there was such a thing you'd find that the problem is essentially difficult.
there seems to be a development team that fully understand the crucial role that pacman plays in Arch and they behave accordingly in relation to rolling out updates.
- Many of these languages allow for quicker development; by raising the abstraction level it's possible to express more complex ideas in fewer lines of code and given that the lines/hour written by a developer is fairly static across languages it leads to quicker development. HOWEVER, pacman doesn't suffer from slow development, there are new releases with new features fairly frequently (probably as frequently as the community can stand them).
According to what _you_ expect from a package manager to do.
Indeed. It's correct (well tested, has stood the test of time, etc) and reliable. That's what I expect of a package manager. Re-writing it in another language would mean starting over with something that's essentially difficult with something a tool that reduces accidental difficulty.
- Finally with each language comes a pool of possible contributors, the group of people who already know, or are willing to learn the language. For C this pool is huge, for most of these hi-level languages not so.
So my conclusion is that when you say "I do think pacman could much better if rewritten in one of these languages", then I say that you most likely are completely wrong. The more likely effect of rewriting pacman in one of these languages is that the current development team would disperse, there wouldn't be as large a pool of programmers to recruit from to replace them, and in the end pacman would turn out to be worse.
Oh, come on. You're kidding me, right? Did anyone talked about spreading in the wild the current team?
You can't possibly misunderstand me to that extent. What I'm trying to say is that you are suggesting something that you haven't thought through properly, if you were to stop and ponder a little you would realise that your suggestion would have the _unintended_ consequences of 1. reduce the pool of possible contributors 2. push away the current contributors who don't know language X and don't want to learn it In other words, the current team would be dispersed. Please read Brook's No Silver Bullet and then return to the discussion. http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBullet.html /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus
The 22/11/11, Magnus Therning wrote:
On Tue, Nov 22, 2011 at 13:02, Nicolas Sebrecht <nsebrecht@piing.fr> wrote:
But it's missing advanced features.
OP raised rollbacks, I'd rather talk about simultaneous/concurrency pacman calls and mutli-threading to handle packages installation where applicable (handling pools of per-package fetch, uncompress & install processes), for example. Or even a _three-way merge_ tool for configuration files (think of dispatch-conf), /etc snapshoting, check for conflicting path namespaces of files over packages at installation time (not sure this check is already done for every file), or whatever smart thing could be implemented.
I'm not saying all of this should be implemented. At least, allowing wide contributions (from the technical POV, with a more simple language) permits nicer discussions and by the end, interesting features to be implemented.
"Simple language"?
I admit it's not the best words. I should rather say "language with a higher level of abstraction letting us to express more complex ideas in fewer lines of code, sometime relying on very small and atomic units of a more low-level language like C for critical pieces of code, giving us the advantages we all know for software maintenance, scalability and adaptability, even for less experienced programmers such as advanced admins" but this is not very concise.
Even if there was such a thing you'd find that the problem is essentially difficult.
Trying to solve a difficult problem, say ones that would need a good level of abstraction, is harder with a language like C than with a high-level language. ,-)
Indeed. It's correct (well tested, has stood the test of time, etc) and reliable. That's what I expect of a package manager. Re-writing it in another language would mean starting over with something that's essentially difficult with something a tool that reduces accidental difficulty.
It's a bit in contradiction with your previous statements. As you said, code source is changing, pacman is moving. Playing with C makes no help to reduce accidental difficulty; it's the exact opposite. Reliability is managed with good software development practices such as development cycle and keep control on too much stressed pieces of code. Starting with another language doesn't mean it should not be well tested.
You can't possibly misunderstand me to that extent. What I'm trying to say is that you are suggesting something that you haven't thought through properly, if you were to stop and ponder a little you would realise that your suggestion would have the _unintended_ consequences of
1. reduce the pool of possible contributors
I don't think, so. IMHO, the pool of contributors is bigger with a high-level language than for C, simply because the learning curve of a good high-level language is much shorter.
2. push away the current contributors who don't know language X and don't want to learn it
With statements like that, even C language would not have become what it is today and we were all running of softwares in B language alone, or so. -- Nicolas Sebrecht
Nicolas Sebrecht, Tue 2011-11-22 @ 16:24:02+0100:
I don't think, so. IMHO, the pool of contributors is bigger with a high-level language than for C, simply because the learning curve of a good high-level language is much shorter.
You can't seriously be suggesting that switching to Haskell would increase the size of the pacman developer pool. I think Haskell is great too, but if you think it's bigger than C just because it's high-level, you're delusional. Even on a distro like Arch, where there seems to be a disproportionate number of Haskell users, I'd wager that there are still far more people here that know C. The learning curve of Haskell is widely regarded as one of the steepest in programming. There are plenty of arguments to be made in its favor, but that is not one of them. C is the lingua franca of Unix, practically everyone knows it, or at least enough of it to be moderately competent. It makes sense to keep community-developed projects like pacman in a widely-known and used language so that more people can understand the code and contribute. I don't think there's any compelling reason to rewrite pacman in another language.
On 11/22/2011 13:36, Taylor Hedberg wrote:
I don't think, so. IMHO, the pool of contributors is bigger with a high-level language than for C, simply because the learning curve of a good high-level language is much shorter. You can't seriously be suggesting that switching to Haskell would increase the size of the pacman developer pool. I think Haskell is great too, but if you think it's bigger than C just because it's high-level, you're delusional. Even on a distro like Arch, where there seems to be a disproportionate number of Haskell users, I'd wager that
Nicolas Sebrecht, Tue 2011-11-22 @ 16:24:02+0100: there are still far more people here that know C.
The learning curve of Haskell is widely regarded as one of the steepest in programming. There are plenty of arguments to be made in its favor, but that is not one of them.
C is the lingua franca of Unix, practically everyone knows it, or at least enough of it to be moderately competent. It makes sense to keep community-developed projects like pacman in a widely-known and used language so that more people can understand the code and contribute. I don't think there's any compelling reason to rewrite pacman in another language.
Code language should not be chosen based on popularity. C is used in most unix-like software because of its quality and not as a consequence of the available developer pool for it. -- Rodrigo
Rodrigo Amorim Bahiense, Tue 2011-11-22 @ 13:43:58-0200:
Code language should not be chosen based on popularity. C is used in most unix-like software because of its quality and not as a consequence of the available developer pool for it.
Maybe not, but the person I was replying to was making the specific argument that higher-level languages like Haskell would be more suitable for a tool like pacman because a larger number of people would be able to contribute. I was simply pointing out the fact that that is certainly not the case for Haskell in particular. I don't think popularity is irrelevant, either, assuming you are interested in increasing the volume of contributions to your project. If you pick a relatively obscure language to work in, you are just creating another barrier that makes it harder for new people to become acquainted with the codebase.
The 22/11/11, Taylor Hedberg wrote:
Maybe not, but the person I was replying to was making the specific argument that higher-level languages like Haskell would be more suitable for a tool like pacman because a larger number of people would be able to contribute. I was simply pointing out the fact that that is certainly not the case for Haskell in particular.
I don't think popularity is irrelevant, either, assuming you are interested in increasing the volume of contributions to your project. If you pick a relatively obscure language to work in, you are just creating another barrier that makes it harder for new people to become acquainted with the codebase.
Here is a very good resume of this aspect of the discussion and we fully agree, here. -- Nicolas Sebrecht
The 22/11/11, Rodrigo Amorim Bahiense wrote:
On 11/22/2011 13:36, Taylor Hedberg wrote:
You can't seriously be suggesting that switching to Haskell would increase the size of the pacman developer pool.
Notice I didn't support Haskell. I'm talking about high-level languages in general. Not all of these languages are widely used nor very scalable for a package manager.
I don't think there's any compelling reason to rewrite pacman in another language.
I already gave some good reasons in this thread, though.
Code language should not be chosen based on popularity. C is used in most unix-like software because of its quality and not as a consequence of the available developer pool for it.
I tend to agree. -- Nicolas Sebrecht
On Tue, Nov 22, 2011 at 04:53:53PM +0100, Nicolas Sebrecht wrote:
The 22/11/11, Rodrigo Amorim Bahiense wrote:
On 11/22/2011 13:36, Taylor Hedberg wrote:
You can't seriously be suggesting that switching to Haskell would increase the size of the pacman developer pool.
Notice I didn't support Haskell. I'm talking about high-level languages in general. Not all of these languages are widely used nor very scalable for a package manager.
Many here will agree to almost all the points that you raised about Haskell. However the way the you introdued might have irked some. Here is how one would go about suggesting such a changes: "Hi folks I was interested to know whether implementing rollbacks like NixOS is interesting for people here. Since I feel that C is too low level as a first step I am attempting a port of pacman to Haskell. The code is available under darcs at http://somewhere.org/me/ Patches are welcome. The current version does nothign but prints package meta info. Regards me"
The 22/11/11, Piyush P Kurur wrote:
Many here will agree to almost all the points that you raised about Haskell. However the way the you introdued might have irked some.
I'm sorry about that. Poor circumstances might give this wrong impression.
Here is how one would go about suggesting such a changes:
"Hi folks I was interested to know whether implementing rollbacks like NixOS is interesting for people here. Since I feel that C is too low level as a first step I am attempting a port of pacman to Haskell. The code is available under darcs at http://somewhere.org/me/ Patches are welcome. The current version does nothign but prints package meta info.
Regards
me"
Notice I'm not the OP show suggested porting pacman to Haskell. I came into this thread after the facts and tried hard to make the original suggestion as a part of the larger POV in favor of high-level languages. Also, I don't want to flame and rather keep the discussion out of free attacks against the current team of developers. I took part of this thread only because I've already been faced to pacman limitations in its current form. -- Nicolas Sebrecht
On Tue, Nov 22, 2011 at 05:16:27PM +0100, Nicolas Sebrecht wrote:
The 22/11/11, Piyush P Kurur wrote:
Notice I'm not the OP show suggested porting pacman to Haskell. I came into this thread after the facts and tried hard to make the original suggestion as a part of the larger POV in favor of high-level languages.
Writing system managing tools in Haskell is not a bad suggestion at all. You might have read about Linspire/Freespire which is a debian based distro having a substantial part written in Haskell (I have not used it so I dont know how much of a success it was).
Also, I don't want to flame and rather keep the discussion out of free attacks against the current team of developers. I took part of this thread only because I've already been faced to pacman limitations in its current form.
NixOS uses a radically differnet and, in my opinion, brilliant idea to support Rollbacks (again I have not used NixOS but have read about them). It keeps all the packages in a different directory called /store if I remember right. Each package is installed in a directory of its own like /store/firefox-version-sha1-hash where the hash will depend on the package source and config options. This kind of architecture allows lots of interesting stuff like user installation and secure sharing of installations by users, multiple versions of the same file, automatic shared library dependency besides atomic rollbacks of course. Overall it is a very promising idea which is also working well (I think) in practice. There are drawbacks of course like large harddisk space for example. Now how much of this will fit with Arch. Very little. Arch has a very different structure. Pacman was not written with this kind of a goal. So I dont see an easy way all this can be achieved with a structure like Arch. Having a great package management is only one part of the story, one still needs the good quality packages. And that is the really hard part. Regards ppk
Taylor Hedberg [2011.11.22 1036 -0500]:
Nicolas Sebrecht, Tue 2011-11-22 @ 16:24:02+0100:
I don't think, so. IMHO, the pool of contributors is bigger with a high-level language than for C, simply because the learning curve of a good high-level language is much shorter.
You can't seriously be suggesting that switching to Haskell would increase the size of the pacman developer pool. I think Haskell is great too, but if you think it's bigger than C just because it's high-level, you're delusional. Even on a distro like Arch, where there seems to be a disproportionate number of Haskell users, I'd wager that there are still far more people here that know C.
The learning curve of Haskell is widely regarded as one of the steepest in programming. There are plenty of arguments to be made in its favor, but that is not one of them.
C is the lingua franca of Unix, practically everyone knows it, or at least enough of it to be moderately competent. It makes sense to keep community-developed projects like pacman in a widely-known and used language so that more people can understand the code and contribute. I don't think there's any compelling reason to rewrite pacman in another language.
I think this discussion has dragged on for too long and the points that should have been made have been made already - so I was reluctant to respond. However, I felt I needed to chime in here to say that I think that Taylor hit the nail on the head. I am a big proponent of Haskell - it's pretty much the only language I use nowadays for any of my toy projects - but it's not an easy language to learn to use effectively. For that reason, the pool of Haskell developers out there is much smaller than the pool of C programmers. Furthermore, from my own experience I know that writing good Haskell code poses its own set of challenges exactly *because* the language is so expressive, not unlike writing Perl code, which in the areas it was designed for is also highly expressive. I sometimes step into the trap of expressing my computation as succinctly as possible...and the result is write-only code where I, being the author of the code, need 5 minutes to figure out what a cleverly crafted 2-line function does when looking at the code 3 months after I wrote it. So, given that the current team behind pacman is using C to develop it and manages to churn out very high-quality code with it, the only reasonable approach to convince people that Haskell would indeed be a better choice is to demonstrate that there exists a group of Haskell-savvy arch users/developers out there that can first reimplement pacman in Haskell, in a way that matches or comes close to the performance of the current C implementation, and can then capitalize on the expressiveness of Haskell to add new features more quickly than would have been possible using the current C implementation, without sacrificing performance, stability or readability of the code. Cheers, Norbert
If I still may: roll-back and reproducible configuration was already proposed in the past? The idea raised by Nix devs was the a purely functional approach was a way to implement it. Of course people can have similar ideas with other techniques. If it a very practical question because I'm sure all Arch users in some point or another had to do a roll-back after a complex system update, and then they find themselves in a difficult situation to figure out how to revert all those changes. Pro Audio users, for instance, might want to have their system configuration in a state just before the change that broke lv2 support on Ardour. Nix approach may be not the only one, but their ideas let people see the difference between same packages build with different libs, or know to set a exact system configuration more easily.
On Tue, Nov 22, 2011 at 8:30 PM, Bernardo Barros <bernardobarros2@gmail.com> wrote:
If I still may:
roll-back and reproducible configuration was already proposed in the past?
The idea raised by Nix devs was the a purely functional approach was a way to implement it. Of course people can have similar ideas with other techniques.
If it a very practical question because I'm sure all Arch users in some point or another had to do a roll-back after a complex system update, and then they find themselves in a difficult situation to figure out how to revert all those changes.
Pro Audio users, for instance, might want to have their system configuration in a state just before the change that broke lv2 support on Ardour.
Nix approach may be not the only one, but their ideas let people see the difference between same packages build with different libs, or know to set a exact system configuration more easily.
I using testing / staging repos does this already: you try out [testing], if it doesn't work, you disable it and run 'pacman -Suu'. Would using different sync dbs and a separate cache turned into a local repo make it easy enough to be practical?
On 11/22/2011 02:41 PM, Karol Blazewicz wrote:
I using testing / staging repos does this already: you try out [testing], if it doesn't work, you disable it and run 'pacman -Suu'. Would using different sync dbs and a separate cache turned into a local repo make it easy enough to be practical?
Also, pacsnap[1] does a good enough job for me. Which is to take maybe 70% of the risk out of upgrading -- sure, a reversion won't work all the time, but I need it rarely enough that the low overhead of pacsnap is more convenient for me than the risk of living with a partly-broken system until it's fixed upstream is bad. That being said, if someone polishes btrfs snapshots, I might use that instead. (Once I switch to btrfs, that is.) [1] http://aur.archlinux.org/packages.php?ID=34290
On Tue, Nov 22, 2011 at 2:05 PM, Isaac Dupree < ml@isaac.cedarswampstudios.org> wrote:
On 11/22/2011 02:41 PM, Karol Blazewicz wrote:
I using testing / staging repos does this already: you try out [testing], if it doesn't work, you disable it and run 'pacman -Suu'. Would using different sync dbs and a separate cache turned into a local repo make it easy enough to be practical?
Also, pacsnap[1] does a good enough job for me. Which is to take maybe 70% of the risk out of upgrading -- sure, a reversion won't work all the time, but I need it rarely enough that the low overhead of pacsnap is more convenient for me than the risk of living with a partly-broken system until it's fixed upstream is bad.
That being said, if someone polishes btrfs snapshots, I might use that instead. (Once I switch to btrfs, that is.)
[1] http://aur.archlinux.org/**packages.php?ID=34290<http://aur.archlinux.org/packages.php?ID=34290>
People keep bringing up btrfs snapshots but no one's mentioned LVM snapshots. Is it not worthwhile? I've been meaning to try it out for a while now.
On Nov 22, 2011 1:30 PM, "Bernardo Barros" <bernardobarros2@gmail.com> wrote:
If I still may:
roll-back and reproducible configuration was already proposed in the past?
The idea raised by Nix devs was the a purely functional approach was a way to implement it. Of course people can have similar ideas with other techniques.
If it a very practical question because I'm sure all Arch users in some point or another had to do a roll-back after a complex system update, and then they find themselves in a difficult situation to figure out how to revert all those changes.
Pro Audio users, for instance, might want to have their system configuration in a state just before the change that broke lv2 support on Ardour.
Nix approach may be not the only one, but their ideas let people see the difference between same packages build with different libs, or know to set a exact system configuration more easily.
The only clear way to achieve clean rollbacks is to snapshot at the FS level ... otherwise things get real complicated, real fast. Some packages are one-way only, eg. Pacman 3.5 upgrade to DB, and "rollback" means saving the original, etc ... As already touched in the thread, btrfs makes this trivial. `mkinitcpio-btrfs` will provide 95% of what's needed already. The hook could definitely use some love but it fulfills the suggested use case nicely, and also allows for comparison between snapshots. C Anthony
On 22 November 2011 14:42, C Anthony Risinger <anthony@xtfx.me> wrote:
On Nov 22, 2011 1:30 PM, "Bernardo Barros" <bernardobarros2@gmail.com> wrote:
If I still may:
roll-back and reproducible configuration was already proposed in the
past?
The idea raised by Nix devs was the a purely functional approach was a way to implement it. Of course people can have similar ideas with other techniques.
If it a very practical question because I'm sure all Arch users in some point or another had to do a roll-back after a complex system update, and then they find themselves in a difficult situation to figure out how to revert all those changes.
Pro Audio users, for instance, might want to have their system configuration in a state just before the change that broke lv2 support on Ardour.
Nix approach may be not the only one, but their ideas let people see the difference between same packages build with different libs, or know to set a exact system configuration more easily.
The only clear way to achieve clean rollbacks is to snapshot at the FS level ... otherwise things get real complicated, real fast.
Some packages are one-way only, eg. Pacman 3.5 upgrade to DB, and "rollback" means saving the original, etc ...
As already touched in the thread, btrfs makes this trivial. `mkinitcpio-btrfs` will provide 95% of what's needed already. The hook could definitely use some love but it fulfills the suggested use case nicely, and also allows for comparison between snapshots.
C Anthony
Honestly I don't know how this topic got so off-topic so quickly! I think it is obvious that pacman will not get rewritten in Haskell, so lets just stop talking about that - arguing over languages is like arguing over window mangers, cmon people! Secondly, I agree that snapshots must be done at a system level. It does not make sense to re-implement something that is already being done better by the file system. I think the OP had some ideas about rolling changes back, I don't think he was really familiar with ARM which handles most of that he was worried about. Remember, you gotta KISS it or else you'll miss it! :-)
A layer above pacman taking advantage of ARM?
On Tue, Nov 22, 2011 at 9:01 PM, Bernardo Barros <bernardobarros2@gmail.com> wrote:
A layer above pacman taking advantage of ARM?
ARM is limited to official repos, but you don't need another layer, just use http://arm.konnichi.com/2011/11/21/ as your server and run 'pacman -Suu' to downgrade.
On (11/22/11 11:30), Bernardo Barros wrote: -~> If I still may: -~> -~> roll-back and reproducible configuration was already proposed in the past? -~> -~> The idea raised by Nix devs was the a purely functional approach was a -~> way to implement it. Of course people can have similar ideas with -~> other techniques. -~> -~> If it a very practical question because I'm sure all Arch users in -~> some point or another had to do a roll-back after a complex system -~> update, and then they find themselves in a difficult situation to -~> figure out how to revert all those changes. -~> -~> Pro Audio users, for instance, might want to have their system -~> configuration in a state just before the change that broke lv2 support -~> on Ardour. -~> -~> Nix approach may be not the only one, but their ideas let people see -~> the difference between same packages build with different libs, or -~> know to set a exact system configuration more easily. But config files are always preserved, and severe breakage is avoided by using testing. Where does the roll-back fit in here? Next, it is OK to have /nix/store/<hash>-gcc, but what about /nix/store/<hash>-libpng? Even a minor upgrade requires relinking? IMHO, somebody needed to write a phd thesis, so this problem came up. As a research project NixOS is fine. But as a sustainable distro it's not. Another example that is unlikely to lift off is Qubes OS which is probably the most secure linux distro, but highly unpractical. The question which I always have in such cases is why not bring your ideas to something already mature like dpkg/rpm? Probably they did ask on respective ML and got rejected after being unable to address the above and similar questions. -- Leonid Isaev GnuPG key ID: 164B5A6D Key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
The 22/11/11, Norbert Zeh wrote:
but it's not an easy language to learn to use effectively. For that reason, the pool of Haskell developers out there is much smaller than the pool of C programmers. Furthermore, from my own experience I know that writing good Haskell code poses its own set of challenges
Agreed. I don't think Haskell is the best language for the purpose. Go language may fit much better. -- Nicolas Sebrecht
On Mon, Nov 21, 2011 at 1:23 PM, Bernardo Barros <bernardobarros2@gmail.com>wrote:
Perhaps the developers want to take a look at this distribution.It is reported that is written in a `purely functional package management' and tries to be a highly safe OS, where `upgrading a system is as reliable as reinstalling from scratch'.
Because the files of a new configuration don’t overwrite old ones, you can (atomically) roll back to a previous configuration. For instance, if after a nixos-rebuild switch you discover that you don’t like the new configuration, you can just go back
It can be an inspiration for a new version of pacman rewritten in haskell? Also Don Stewart's talk about 'Scripting with Types' might inspire someone too (BTW since he started arch-haskell I think he is a Arch user):
Here's my 2 cents. If you want nixos, just use nixos. -- "Breathe Deeply and Dream"
participants (20)
-
Bernardo Barros
-
Buce
-
C Anthony Risinger
-
Calvin Morrison
-
Clive Cooper
-
Isaac Dupree
-
Jeffrey Lynn Parke Jr.
-
Jelle van der Waa
-
Karol Blazewicz
-
Leonid Isaev
-
Magnus Therning
-
Nicolas Sebrecht
-
Norbert Zeh
-
Paul Gideon Dann
-
Pierre Schmitz
-
Piyush P Kurur
-
Rodrigo Amorim Bahiense
-
Rogutės Sparnuotos
-
Taylor Hedberg
-
Thorsten Töpper