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
-
On Tue, Nov 22, 2011 at 2:05 PM, Isaac Dupree <
m...@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 diffe
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?
Al
On Tue, Nov 22, 2011 at 9:01 PM, Bernardo Barros
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.
A layer above pacman taking advantage of ARM?
On 22 November 2011 14:42, C Anthony Risinger wrote:
> On Nov 22, 2011 1:30 PM, "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
>
On Nov 22, 2011 1:30 PM, "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
> othe
On Tue, Nov 22, 2011 at 8:30 PM, 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
>
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 a
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
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 fav
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
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
On 11/22/2011 13:36, Taylor Hedberg wrote:
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
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 wo
On Tue, Nov 22, 2011 at 13:02, Nicolas Sebrecht 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
On 22 November 2011 11:20, Magnus Therning 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
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 f
On Tue, Nov 22, 2011 at 12:02, Nicolas Sebrecht wrote:
> The 22/11/11, Karol Blazewicz wrote:
>> On Tue, Nov 22, 2011 at 10:50 AM, Nicolas Sebrecht
>> 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 l
On Tue, Nov 22, 2011 at 12:06 PM, Jelle van der Waa 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
>>> wrote:
>>
OP raised one or two benefits of Haskell over shell scripting. He is
>>>
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 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 adva
On Tue, Nov 22, 2011 at 10:50 AM, Nicolas Sebrecht 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 developme
On Mon, Nov 21, 2011 at 2:03 PM, Bernardo Barros
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
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 f
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 i
On Mon, Nov 21, 2011 at 1:23 PM, Bernardo Barros
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
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 inspiri
On (11/21/11 11:43), Bernardo Barros wrote:
-~> On Mon, Nov 21, 2011 at 11:40 AM, 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."
-~> >
-~>
-~> Hello Thorste
On Mon, Nov 21, 2011 at 8:58 PM, Pierre Schmitz wrote:
> Am 21.11.2011 20:43, schrieb Bernardo Barros:
>> On Mon, Nov 21, 2011 at 11:40 AM, 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
Am 21.11.2011 20:43, schrieb Bernardo Barros:
> On Mon, Nov 21, 2011 at 11:40 AM, 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."
>>
>
> Hello Thorsten, no, you got it
Bernardo Barros (2011-11-21 11:43):
> On Mon, Nov 21, 2011 at 11:40 AM, 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."
> >
>
> Hello Thorsten, no, you got it wrong.
Those guys wrote their ideas down here for those interested:
http://www.st.ewi.tudelft.nl/~dolstra/pubs/nixos-jfp-final.pdf
On Mon, Nov 21, 2011 at 11:40 AM, 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."
>
Hello Thorsten, no, you got it wrong.
It's about ideas not languages. I think it makes s
On Mon, 21 Nov 2011 11:23:58 -0800
Bernardo Barros 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 f
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 n
35 matches
Mail list logo
