On 1/13/24 10:55, Alan Coopersmith wrote:
Someone looking to improve that might want to check out the recent
performance improving commits to
https://github.com/oracle/solaris-ips/commits/master/ and see if
they cherry-pick to OI's fork.
-alan-
Thanks for pointing that out, Alan. My OI
given that this is the "discuss" and not the "dev" list, i think this thread is
doing just fine.
On Sat, 13 Jan 2024 16:36:59 -0800, Joshua M. Clulow via openindiana-discuss
wrote:
> I think this thread has achieved all it's likely to achieve. If
> people want to work on IPS, there are any
On Sat, 13 Jan 2024 at 16:18, Goetz T. Fischer wrote:
> no, such a comparison would of course be pointless.
On Sat, 13 Jan 2024 at 16:30, Goetz T. Fischer wrote:
> On Sat, 13 Jan 2024 15:36:40 -0800, Bill Sommerfeld via openindiana-discuss
> wrote:
> > don't assume the SAT solver is eating it
i would assume it's eating most of it because on an old machine, the assigned
cpu core is at 100% for
several minutes while the rotating slash keeps, well, rotating.
disk writes wouldn't cause 100% cpu. in fact, having a slow disk brings the cpu
load down if the disk
can't keep up.
On Sat, 13
no, such a comparison would of course be pointless.
On Sat, 13 Jan 2024 23:47:04 +, aurelien.larc...@gmail.com wrote:
> Probably a difference in hardware then.
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
Am 14.01.24 um 00:36 schrieb Bill Sommerfeld via openindiana-discuss:
On 1/13/24 15:20, Andreas Wacknitz via openindiana-discuss wrote:
Am 14.01.24 um 00:13 schrieb Goetz T. Fischer:
i'm afraid making ips fast needs more than just a cython module here
and there.
don't get me wrong, that's not
Le Samedi 13 janvier 2024, Goetz T. Fischer a écrit :
> oh yes, that is the case for any kind of upgrades because while ips is still
> rotating the slash, the
> others are half-way through already. i've done rhel upgrades after 1 1/2
> years and they were
> significantly faster than ips
On 1/13/24 15:20, Andreas Wacknitz via openindiana-discuss wrote:
Am 14.01.24 um 00:13 schrieb Goetz T. Fischer:
i'm afraid making ips fast needs more than just a cython module here
and there.
don't get me wrong, that's not indiana's fault but a genernal ips
issue. maybe having a closer look
no, and i never said that. i'm just posting my observations because of the
direction this topic headed
to.
besides, if i'm not mistaken this would be the wrong list for such things
anyway i.e. not the dev list.
On Sun, 14 Jan 2024 00:20:36 +0100, Andreas Wacknitz via openindiana-discuss
Am 14.01.24 um 00:13 schrieb Goetz T. Fischer:
i'm afraid making ips fast needs more than just a cython module here and there.
don't get me wrong, that's not indiana's fault but a genernal ips issue. maybe
having a closer look at
mr. Wegmueller's go version would be a good idea after all.
If
i'm afraid making ips fast needs more than just a cython module here and there.
don't get me wrong, that's not indiana's fault but a genernal ips issue. maybe
having a closer look at
mr. Wegmueller's go version would be a good idea after all.
On Sun, 14 Jan 2024 00:05:18 +0100, Andreas Wacknitz
Am 13.01.24 um 17:55 schrieb Alan Coopersmith:
On 1/13/24 08:41, Goetz T. Fischer wrote:
the first and foremost problem of ips is speed.
Someone looking to improve that might want to check out the recent
performance
improving commits to
https://github.com/oracle/solaris-ips/commits/master/
oh yes, that is the case for any kind of upgrades because while ips is still
rotating the slash, the
others are half-way through already. i've done rhel upgrades after 1 1/2 years
and they were
significantly faster than ips upgrades after a month.
just because they handle download and
Le Samedi 13 janvier 2024, Goetz T. Fischer a écrit :
> i don't know about plain apt but aptitude, yum or zypper are lightyears
> faster than ips no matter how
> many updates are pending.
No that is the not the case for large upgrades.
The reason is that apt/yum and the likes unpack each
i don't know about plain apt but aptitude, yum or zypper are lightyears faster
than ips no matter how
many updates are pending.
On Sat, 13 Jan 2024 18:07:49 +, aurelien.larc...@gmail.com wrote:
> IPS scales better w.r.t the number of packages installed and therefore is
> faster than apt
Le Samedi 13 janvier 2024, Goetz T. Fischer a écrit :
> as much as i value playful adventures, system stuff should always be c/c++.
> the last thing one would
> want is to add even more stuff that can't be uninstalled because of maybe
> only one single dependency.
>
> the first and foremost
On 1/13/24 08:41, Goetz T. Fischer wrote:
the first and foremost problem of ips is speed.
Someone looking to improve that might want to check out the recent performance
improving commits to https://github.com/oracle/solaris-ips/commits/master/ and
see if they cherry-pick to OI's fork.
as much as i value playful adventures, system stuff should always be c/c++. the
last thing one would
want is to add even more stuff that can't be uninstalled because of maybe only
one single dependency.
the first and foremost problem of ips is speed. it's so slow that i had to
write my own
Glady. I made some experiments that went relatively far one being a repo
format implementation in Golang[0] and one being some of that work being
ported to rust [1].
-Till
[0] https://github.com/Toasterson/pkg6-go
[1] https://github.com/openflowlabs/ips
On 13.01.2024 13:02, Matthew R. Trower
Ah okay, thanks for the clarification. There are a number of items I’d dearly
like to improve about IPS, but none of them are something to tackle on a whim.
I guess I’ll add metadata caching behavior to the list. Maybe once I get some
more immediate matters off my plate, we can revisit this.
Hi Mathew
It is a special statement for /var/pkg/publisher you will get stale data
due to how the Metadata download process works. This directory MUST
always go forward in time from it's perspective. Meaning it MUST be
inside the Boot Environment. At least as long as nobody rewrites that :)
On 1/12/24 18:51, Bill Sommerfeld via openindiana-discuss wrote:
> Today, illumos-gate has only attributes(7).
>
> I believe you have stale preformatted man pages from a system installed
> before https://www.illumos.org/issues/14443 landed, likely in
> /usr/man/cat?/ directories that are no
On 1/12/24 16:06, Matthew R. Trower wrote:
Interesting, I only knew of attributes(5). It appears attributes(7) may
have shared a common root, but has long since diverged (or maybe they're
just encoded differently). Still, they appear identical in regards to
the Interface Stability attribute.
Hi Till,
To clarify, I only wish to share /var/pkg/publisher. /var/pkg clearly
contains image-specific data, and bad bad things would happen if that
were shared.
Does your statement still apply specifically to /var/pkg/publisher?
-- Matthew R. Trower
On 1/12/24 12:25, Till Wegmueller
On 1/12/24 08:49, Marcel Telka wrote:
On Fri, Jan 12, 2024 at 08:21:17AM -0600, Matthew R. Trower wrote:
On 1/12/24 04:41, Marcel Telka wrote:
On Fri, Jan 12, 2024 at 04:08:12AM -0600, Matthew R. Trower
wrote:
/var/pkg/publisher is exactly what I thought it was. I am
still not clear as
Hi,
From personal experience, Yes this data is kind of a cache. It is later
merged into the publisher independant JSON. However you MUST NOT share
this between BE's this directory is not safe to go back in time due to
how partial download and merging works. Do NOT share /var/pkg between BE's
On 1/12/24 06:49, Marcel Telka wrote:
On Fri, Jan 12, 2024 at 08:21:17AM -0600, Matthew R. Trower wrote:
If uninstalling a package places files in lost+found, then I'm well and
truly confused.
To confuse you a bit more here is an example:
# find /var/pkg/lost+found/ -type f
# echo test >
On Fri, Jan 12, 2024 at 08:21:17AM -0600, Matthew R. Trower wrote:
>
> On 1/12/24 04:41, Marcel Telka wrote:
> > On Fri, Jan 12, 2024 at 04:08:12AM -0600, Matthew R. Trower wrote:
> > > /var/pkg/publisher is exactly what I thought it was. I am still not
> > > clear as to whether the format is
On 1/12/24 04:41, Marcel Telka wrote:
On Fri, Jan 12, 2024 at 04:08:12AM -0600, Matthew R. Trower wrote:
/var/pkg/publisher is exactly what I thought it was. I am still
not clear as to whether the format is committed(stable) across
different versions of pkg5, and therefore safe to share
On Fri, Jan 12, 2024 at 04:08:12AM -0600, Matthew R. Trower wrote:
> /var/pkg/publisher is exactly what I thought it was. I am still not clear
> as to whether the format is committed(stable) across different versions of
> pkg5, and therefore safe to share across BEs.
The man page says:
Interface
On 1/12/24 03:19, Marcel Telka wrote:
On Thu, Jan 11, 2024 at 11:16:21PM -0600, Matthew R. Trower wrote:
Is the format of /var/pkg/publisher committed at this point? It looks to
contain cached data and downloads from publishers, which ought not to be
tied to any particular BE. If I create a
On Thu, Jan 11, 2024 at 11:16:21PM -0600, Matthew R. Trower wrote:
> Is the format of /var/pkg/publisher committed at this point? It looks to
> contain cached data and downloads from publishers, which ought not to be
> tied to any particular BE. If I create a ZFS dataset to share that among
>
Hi,
Is the format of /var/pkg/publisher committed at this point? It looks
to contain cached data and downloads from publishers, which ought not to
be tied to any particular BE. If I create a ZFS dataset to share that
among BEs, am I going to run into trouble?
What exactly are the contents
33 matches
Mail list logo