Re: Linux installer as jar?
On 2020-06-28 09:34, Dr. Arne Babenhauserheide wrote: > Steve Dougherty writes: > >> I can't speak for Arne but as far as I'm aware the things I mentioned >> in my quoted message still apply: we'd need to write a way for the >> package to update itself over Freenet. > > While I think that this would be ideal, I also think that most users do > not need update over Freenet, since it only gives them a privacy > advantage, when they run full darknet. > > The Gentoo package for example does not update over Freenet. > > The distributions usually do their own quality control and update with a > delay, and while that makes measuring the update-process a bit harder, > it would also give some additional security against a Freenet release > manager going rogue. > > Best wishes, > Arne BTW there was a discussion about including it to Debian before: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481163
Re: Linux installer as jar?
On 2020-06-28 09:34, Dr. Arne Babenhauserheide wrote: > Steve Dougherty writes: > >> I can't speak for Arne but as far as I'm aware the things I mentioned >> in my quoted message still apply: we'd need to write a way for the >> package to update itself over Freenet. > > While I think that this would be ideal, I also think that most users do > not need update over Freenet, since it only gives them a privacy > advantage, when they run full darknet. > > The Gentoo package for example does not update over Freenet. > > The distributions usually do their own quality control and update with a > delay, and while that makes measuring the update-process a bit harder, > it would also give some additional security against a Freenet release > manager going rogue. > > Best wishes, > Arne Those are all good points. We know that package maintainers may take a while to catch up with the latest releases. There is software that choose not to provide official packages (ie, Calibre). Here are two points (pro and con) about having packages: # Ease of install and update Requiring only a few commands to have a running node would make it easier for new comers to install Freenet and test it out. Updating would also be just a command away. # Outdated nodes If the node update depends on the OS package it's probably that nodes become outdated. It's important to note that self-update goes against the idea of a OS package (ie, updates over Freenet). By that I mean that the package should no modify it's installation by other mean than by the OS package manager. Freenet should be able to determine the installation method and provide (or not) updates over Freenet). I'll take a look at how Google Chrome package does it's magic. So, if we can provide both 1) Ease of install and update and 2) Keep the nodes up-to-date we should go for it. Best regards,
Re: Linux installer as jar?
Steve Dougherty writes: > I can't speak for Arne but as far as I'm aware the things I mentioned > in my quoted message still apply: we'd need to write a way for the > package to update itself over Freenet. While I think that this would be ideal, I also think that most users do not need update over Freenet, since it only gives them a privacy advantage, when they run full darknet. The Gentoo package for example does not update over Freenet. The distributions usually do their own quality control and update with a delay, and while that makes measuring the update-process a bit harder, it would also give some additional security against a Freenet release manager going rogue. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken signature.asc Description: PGP signature
Re: Linux installer as jar?
‐‐‐ Original Message ‐‐‐ On Saturday, June 27, 2020 10:05 PM, DC* wrote: > On 2019-04-13 21:47, Steve Dougherty wrote: > > > My impulse would be to decide which distros we want to officially > > support, and provide packages for them. Perhaps Arch, Debian, and > > Ubuntu? Both installers for Linux applications and compiling Java to > > native code strike me as odd approaches that go against the grain of > > usual software installation, and while I'm not opposed to having them > > as options for distros we don't have packages for, it does seem liable > > to increase our support load. > > Providing packages would allow giving upgrades some nice properties as > > well - instead of having to write upgrade logic ourselves, the package > > manager can do it. We need only (expose and) add a package repo like > > the Google Chrome package does by default. A tool to mirror a USK to > > disk would be useful here; if memory serves I've written up ideas > > about this in the past. > > ‐‐‐ Original Message ‐‐‐ > > On Friday, April 12, 2019 4:31 PM, Arne Babenhauserheide > > arne_...@web.de wrote: > > > > > Hi, > > > With Java 11 Webstart is no longer part of the official > > > distribution. JNLP files no longer start by default. > > > What do you think about just providing the jar? > > > Or should we try whether we can get the installer compiled with Graal? > > > https://www.graalvm.org/docs/getting-started/#native-images > > > Best wishes, > > > Arne > > > > > > Unpolitisch sein > > > heißt politisch sein > > > ohne es zu merken > > What abouthttps://github.com/freenet/debian? With a Debian package you > cover all Debian-based distros, including Ubuntu and derivatives, adding > CentOS/Fedora you cover most OSes. I'm not taking into account MacOS or > Windows. > > What needs to be done to move it forward? > > Best regards, I can't speak for Arne but as far as I'm aware the things I mentioned in my quoted message still apply: we'd need to write a way for the package to update itself over Freenet. (And for the release scripts to support building and releasing the package, but that's probably the easier part of the problem.) If we write a plugin that watches a USK and writes the contents of the latest edition to disk, then the package can set the package manager (so, apt, in this case) to watch that directory for updates. At least if I were still release manager I'd want it to be enabled and configured by default when Freenet is installed via this package, possibly also shipping with default apt-source content if apt yells when pointed at an empty directory. (But as long as it doesn't error out, it'd be acceptable not to do this.)
