Re: Introducing Guix "Features"! (Was: Syntactic Diabetes)
> In the systemd realm, there are different types of services, I think one > is called "one-shot" which is effectively quite similar to the types of > services guix has... they do something once, and there is no running > daemon. So, for better or worse, guix is not so far from one of the most > widespread and commonly used systems here... executed at each boot vs. executed when compiling the system (i.e. at different stages, as in 'staged computation'). it's a bit like using the same word to describe macros and functions in lisp: yes, deep down they are both just functions, but they are different enough to warrant a different name to facilitate a more efficient human comprehension. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “The nation that will insist on drawing a broad line of demarcation between the fighting man and the thinking man is liable to find its fighting done by fools and its thinking done by cowards.” — Sir William Francis Butler (1838–1910)
Re: Introducing Guix "Features"! (Was: Syntactic Diabetes)
On 2024-02-02, Attila Lendvai wrote: >> > for an average unix user a service is a process that is running in the >> > backgroud, doing stuff mostly without any user interaction. you can >> > try to argue this away, but i'm afraid that this is the state of >> > things. >> >> >> I don’t think it’s a good idea to aim to satisfy some presumed “average >> unix user”, because such a user would not be familiar with many concepts >> introduced by Guix (e.g. “guix shell” or “guix system”). > > > the primary argument was that two, very different abstractions share the same > name, and in shared contexts. > > it's just icing on the cake that one of the abstractions is nothing like what > most users understand by the name 'service'. In the systemd realm, there are different types of services, I think one is called "one-shot" which is effectively quite similar to the types of services guix has... they do something once, and there is no running daemon. So, for better or worse, guix is not so far from one of the most widespread and commonly used systems here... live well, vagrant signature.asc Description: PGP signature
Re: Introducing Guix "Features"! (Was: Syntactic Diabetes)
> Am Donnerstag, dem 01.02.2024 um 20:30 + schrieb Attila Lendvai: > > > for an average unix user a service is a process that is running in > > the backgroud, doing stuff mostly without any user interaction. you > > can try to argue this away, but i'm afraid that this is the state of > > things. > > Which is exactly what etc-service-type does. It symlinks stuff to /etc > without user interaction. we can spend our life honing in on a satisfying definition, but let it be enough that what is commonly understood as a service has an active component (see 'run' in my definition); i.e. it has a temporal dimension. but honestly? it felt silly to even provide a definition in my mail. we either live in a different universe, or you're just focused on justify the status quo. whichever is the case, we have reached a dead end, because essentially, this is aesthetics. but anyway, i gave my feedback, and as i don't have the authority to lobby for renaming core guix abstractions, i'm out. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Until you figure out that [manipulation] is going on, we're all going to be run like rats through a maze. Culture is an intelligence test, and when you pass that test you don't give a shit about culture.” — Terence McKenna (1946–2000)
Re: Introducing Guix "Features"! (Was: Syntactic Diabetes)
> > for an average unix user a service is a process that is running in the > > backgroud, doing stuff mostly without any user interaction. you can > > try to argue this away, but i'm afraid that this is the state of > > things. > > > I don’t think it’s a good idea to aim to satisfy some presumed “average > unix user”, because such a user would not be familiar with many concepts > introduced by Guix (e.g. “guix shell” or “guix system”). the primary argument was that two, very different abstractions share the same name, and in shared contexts. it's just icing on the cake that one of the abstractions is nothing like what most users understand by the name 'service'. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “If you love somebody, let them go, for if they return, they were always yours. If they don’t, they never were.” — Khalil Gibran (1883–1931)
Re: Git-LFS or Git Annex?
git-annex, 1% :) It's not as popular, but it's much more powerful, and is some of my favorite software! Ludovic Courtès writes: > Hello! > > I’m looking for ways to incorporate videos into the repositories of our > web sites so they’re content-addressed and properly tracked, and to make > it easier to create backups (right now those videos are stored on our > two main servers and rsynced between them⁰; I’m talking about the videos > at guix.gnu.org, 10years.guix.gnu.org, and hpc.guix.info). > > The question boils down to: Git-LFS or Git Annex? > > From a quick look (I haven’t used them), Git-LFS seems to assume a > rather centralized model where there’s an LFS server sitting next to the > Git server¹. Git Annex looks more decentralized, allowing you to have > several “remotes”, to check the status of each one, to sync them, etc.² > Because of this, Git Annex seems to be a better fit. > > Data point: guix.gnu.org source is hosted on Savannah, which doesn’t > support Git-LFS; the two other web sites above are hosted on GitLab > instances, which I think do support Git-LFS. > > What’s your experience? What would you suggest? > > Thanks, > Ludo’. > > ⁰ > https://git.savannah.gnu.org/cgit/guix/maintenance.git/tree/hydra/berlin.scm#n193 > ¹ https://github.com/git-lfs/git-lfs/wiki/Tutorial > ² https://git-annex.branchable.com/walkthrough/
