Re: Does Intel driver supports Intel g31?

[Родин Максим]

Clearly Russia is guilty of everything in this world.
But Kazakhstan is not Russia.
And your post shows that stupid people live not only in Kazakhstan.

11.04.2020 18:24, m brandenberg пишет:

On Sat, 11 Apr 2020, Nikita Stepanov wrote:


Does Intel driver supports Intel g31?


Clearly, Russia's GRU has been tasked with killing Theo by aneurism.

--
Monty Brandenberg



--

Maksim Rodin

webmaster@ (was: RE: openbsd.org down?)

[zeurkous]

Haai,

mewrote:
> Cc'ing webmaster@ (assuming it exists).

That didn't go so well: a "mailing list expansion problem", apparently
on the side of mail.openbsd.org. Since it ain't an obvious rejection,
me's informed postmaster@. 

 --zeur.

-- 
Friggin' Machines!

RE: openbsd.org down?

[zeurkous]

"Durial EB"  wrote:
> Still down for me.

Appears intermittent. Cc'ing webmaster@ (assuming it exists).

 --zeurkous.

> On Sun, Apr 12, 2020 at 5:44 PM  wrote:
>
>> > Hello.
>> >
>> > What happened to the openbsd.org?
>> > I seems to be down for 10+ hours for now.
>>
>> WFM. Empty your name swerver cache, it might help.
>>
>> > Regards,
>> >
>> > Roman
>>
>> --zeur.
>>
>> -- 
>> Friggin' Machines!

-- 
Friggin' Machines!

Re: openbsd.org down?

[Durial EB]

Still down for me.

On Sun, Apr 12, 2020 at 5:44 PM  wrote:

> > Hello.
> >
> > What happened to the openbsd.org?
> > I seems to be down for 10+ hours for now.
>
> WFM. Empty your name swerver cache, it might help.
>
> > Regards,
> >
> > Roman
>
>   --zeur.
>
> --
> Friggin' Machines!
>
>

Re: Iridium vs Chromium

[Erling Westenvik]

On Sun, Apr 12, 2020 at 10:18:13PM +0100, Patrick Harper wrote:
> My understanding of -current is that it is meant for testing, not usage.

On the contrary. Or at least: for testing, BY usage!

Cheers,
Erling

> -- 
>   Patrick Harper
>   paia...@fastmail.com
> 
> On Sun, 12 Apr 2020, at 21:38, Kevin Chadwick wrote:
> > On April 12, 2020 7:07:01 PM UTC, Patrick Harper  
> > wrote:
> > >The effort to support Chromium and Firefox (sans ESR) on OpenBSD akin
> > >to Windows/macOS/'Linux' has not happened.
> > 
> > On atleast current as Theo showed, Chromium is just as well if not 
> > better supported on OpenBSD than on Linux, these days.
> > 
> > I assume you are judging by a while ago. Or perhaps you mean Chrome 
> > where pre-built binaries for Linux are released by Google? I used to 
> > install chrome on debian/ubuntu to get the extra days.

Re: Iridium vs Chromium

[Allan Streib]

Patrick Harper  writes:

> My understanding of -current is that it is meant for testing, not usage.

Not strictly true. Depends on your needs, and tolerance for things not
always working perfectly.

Allan

Re: Iridium vs Chromium

[Patrick Harper]

I'm puzzled that you thought my statements were a complaint.

-- 
  Patrick Harper
  paia...@fastmail.com

On Sun, 12 Apr 2020, at 22:30, Theo de Raadt wrote:
> Patrick Harper  wrote:
> 
> > I mean that all Chromium releases are made available for OpenBSD-stable 
> > (excluding the previous release at any given time, as with all existing 
> > port maintenance).
> 
> So you want constant Chromium updates in -stable.
> 
> Who's going to do that?
> 
> Are you going to do it?
> 
> And why pick only on Chromium.  Should the same policy be to update all
> *all* packages to -stable, all the time, continuously?
> 
> Who's going to do that?
> 
> Won't we need twice as many people, so that -current ports are maintained,
> as well as -stable ports?  Or if we can't find more people, won't that mean
> a reduction in development of packages in the next release?  Which means
> that -current won't get updated, which means -stable will fall behind
> even further?
> 
> You don't seem to know this:  -stable is done by *one person*
>  
> > My understanding of -current is that it is meant for testing, not usage.
> 
> -current turns into a -release.  So if you don't want good -release,
> which will be followed by good -stable, then how do you think this is
> going to work?
> 
> You don't think.  You just believe deliverable-product you can conceive
> of being possible, should be delivered to you.  Probably on a silver
> plate?
> 
> I believe I've identified the problem precisely.  It is not a software
> problem, it is a people with out-of-touch expectation problem.  It may be
> connected to "the less people pay, the more they expect".  It might also
> be connected to "wow this group looks open, I can participate by demanding
> they do things for me".
> 
> 
>

Re: openbsd.org down?

[Mihai Popescu]

Maybe to much download from ftp.openbsd.org?
It is up now openbsd.org

RE: openbsd.org down?

[zeurkous]

> Hello.
>
> What happened to the openbsd.org?
> I seems to be down for 10+ hours for now.

WFM. Empty your name swerver cache, it might help.

> Regards,
>
> Roman

  --zeur.

-- 
Friggin' Machines!

Re: Iridium vs Chromium

[Theo de Raadt]

Patrick Harper  wrote:

> I mean that all Chromium releases are made available for OpenBSD-stable 
> (excluding the previous release at any given time, as with all existing port 
> maintenance).

So you want constant Chromium updates in -stable.

Who's going to do that?

Are you going to do it?

And why pick only on Chromium.  Should the same policy be to update all
*all* packages to -stable, all the time, continuously?

Who's going to do that?

Won't we need twice as many people, so that -current ports are maintained,
as well as -stable ports?  Or if we can't find more people, won't that mean
a reduction in development of packages in the next release?  Which means
that -current won't get updated, which means -stable will fall behind
even further?

You don't seem to know this:  -stable is done by *one person*
 
> My understanding of -current is that it is meant for testing, not usage.

-current turns into a -release.  So if you don't want good -release,
which will be followed by good -stable, then how do you think this is
going to work?

You don't think.  You just believe deliverable-product you can conceive
of being possible, should be delivered to you.  Probably on a silver
plate?

I believe I've identified the problem precisely.  It is not a software
problem, it is a people with out-of-touch expectation problem.  It may be
connected to "the less people pay, the more they expect".  It might also
be connected to "wow this group looks open, I can participate by demanding
they do things for me".

openbsd.org down?

[Roman Samoilenko]

Hello.

What happened to the openbsd.org?
I seems to be down for 10+ hours for now.


Regards,

Roman

Re: Iridium vs Chromium

[Patrick Harper]

I mean that all Chromium releases are made available for OpenBSD-stable 
(excluding the previous release at any given time, as with all existing port 
maintenance).

My understanding of -current is that it is meant for testing, not usage.

-- 
  Patrick Harper
  paia...@fastmail.com

On Sun, 12 Apr 2020, at 21:38, Kevin Chadwick wrote:
> On April 12, 2020 7:07:01 PM UTC, Patrick Harper  wrote:
> >The effort to support Chromium and Firefox (sans ESR) on OpenBSD akin
> >to Windows/macOS/'Linux' has not happened.
> 
> On atleast current as Theo showed, Chromium is just as well if not 
> better supported on OpenBSD than on Linux, these days.
> 
> I assume you are judging by a while ago. Or perhaps you mean Chrome 
> where pre-built binaries for Linux are released by Google? I used to 
> install chrome on debian/ubuntu to get the extra days.
> 
>

Re: Iridium vs Chromium

[Kevin Chadwick]

On April 12, 2020 7:07:01 PM UTC, Patrick Harper  wrote:
>The effort to support Chromium and Firefox (sans ESR) on OpenBSD akin
>to Windows/macOS/'Linux' has not happened.

On atleast current as Theo showed, Chromium is just as well if not better 
supported on OpenBSD than on Linux, these days.

I assume you are judging by a while ago. Or perhaps you mean Chrome where 
pre-built binaries for Linux are released by Google? I used to install chrome 
on debian/ubuntu to get the extra days.

Re: Iridium vs Chromium

[Patrick Harper]

The effort to support Chromium and Firefox (sans ESR) on OpenBSD akin to 
Windows/macOS/'Linux' has not happened.

-- 
  Patrick Harper
  paia...@fastmail.com

On Sun, 12 Apr 2020, at 16:49, Raymond, David wrote:
> My problem with iridium is that it is based on an older version of
> chromium and I am not sure that they keep up with inevitable flow of
> security fixes.  That said, I am a bit nervous about OpenBSD's lags in
> keeping up with browser security fixes.  (I'm not criticizing -- I
> understand that OpenBSD is a small operation without the people needed
> to keep track of non-core packages.  And I just converted from Arch
> Linux, in which the storm of updates and resulting incompatibilities
> drove me crazy and contributed to my shift to OpenBSD.  Still, I am a
> bit nervous about even slightly out-of-date browsers at this point and
> I am not sure that iridium is an improvement in this regard.)
> 
> Dave
> 
> On 4/12/20, Elias M. Mariani  wrote:
> > I'm not much of a browser savy guy.
> > Is Iridium really safer than Chromium?
> > Leaving aside the "Google is tracking you!".
> >
> > Any recommendations on the browser front on performance, security and
> > compatibility?
> > I've been using Chrome and Chromium for years, but maybe there are
> > better alternatives that I'm unaware of...
> >
> > Cheers.
> > Elias.
> >
> >
> 
> 
> -- 
> David J. Raymond
> david.raym...@nmt.edu
> http://physics.nmt.edu/~raymond
> 
>

Re: Apr 9 snapshot bsd.mp fails on VMware

[j]

Reviewing sizes of /bsd*, they looked odd. So after
a bunch of poking and checking a new install on a 
new VM (which worked) I manually rebuilt the MP kernel
from the SP boot.  And got this:

# ls -l /bsd*
-rwx--  1 root  wheel  18622131 Apr 12 18:01 /bsd
-rwx--  1 root  wheel  17806667 Apr 11 00:15 /bsd.booted
-rw---  1 root  wheel  10351321 Apr 11 00:13 /bsd.rd
-rwx--  1 root  wheel  18532909 Apr 11 00:13 /bsd.sp

However this failed to boot as well (same symptom).  Eventually
I did the obvious thing: copied /home/_sysupgrade/bsd.mp to /
and booted that and it worked, including successful reorder_kernel.

I had missed this syslog entry:

Feb 25 16:48:21 o67snap reorder_kernel: failed -- see 
/usr/share/relink/kernel/GEN
ERIC.MP/relink.log

No idea what happened there.

My fault for not paying attention to syslog.  Sorry for the noise.

John

Re: Iridium vs Chromium

[Raymond, David]

Theo,

Thanks for your explanations.  I appreciate the efforts of you and
your colleagues in keeping OpenBSD as up to date and secure as
possible.  That is one of the main reasons I am using it.

Dave Raymond

On 4/12/20, Theo de Raadt  wrote:
> Raymond, David  wrote:
>
>> That said, I am a bit nervous about OpenBSD's lags in
>> keeping up with browser security fixes.
>
> It isn't that simple.
>
> They don't ship security fixes standalone.  Instead, they ship a mix of
> new changes *and* fixes.  Lots of new unrelated changes, and only a few
> security fixes.  These fixes cannot be plausibly seperated out, as doing
> such a seperate procedure would increase the development workload, and
> increase the update lag.  So instead this software is accepted from
> mainstream
> on the assumption of their best effort, and then the following happens:
>
> The large changesets requires evaluation and verification, to ensure it
> still works with the pledge/unveil changes.  The pledge/unveil changes
> introduce a tighter sandbox than other operating systems have.  Quite
> often, upstream performs operations in the wrong order, and robert finds
> this out during test.  This friction slows the development a little.
>
> But I believe you are completely wrong about how long this lag is.
> You are being inaccurate because you don't know, and making it sound
> like the lagg is many months.
>
> 81.0.4044.92 came out 5 days ago, and here you can see it enter the ports
> tree 2 days ago.
>
> 1 hour ago it was replaced with a newer update.
>
> date: 2020/04/10 18:51:30;  author: robert
> update to 81.0.4044.92;
> date: 2020/04/03 13:44:40;  author: robert
> update to 80.0.3987.163
> date: 2020/04/01 12:32:05;  author: robert
> update to chromium-80.0.3987.162;
> date: 2020/03/21 14:08:01;  author: robert
> update to 80.0.3987.149 and apply the following changes:
> date: 2020/03/11 23:57:03;  author: espie
> date: 2020/03/04 15:44:17;  author: robert
> update to 80.0.3987.132 and fix the component flavor while here
> date: 2020/02/22 12:33:20;  author: robert
> update to 80.0.3987.116;
> date: 2020/01/17 20:43:38;  author: robert
> update to 79.0.3945.130
> date: 2020/01/08 14:43:32;  author: robert
> update to 79.0.3945.117
> date: 2019/12/18 09:01:35;  author: robert
> update to 79.0.3945.88
> date: 2019/12/15 12:03:46;  author: robert
> update to 79.0.3945.79
> date: 2019/11/20 18:26:30;  author: robert
> update to 78.0.3904.106
> date: 2019/11/07 10:47:41;  author: robert
> update to 78.0.3904.97
> date: 2019/11/05 22:30:26;  author: robert
> update to 78.0.3904.87
> date: 2019/10/22 18:35:43;  author: robert
> update to 77.0.3865.120 and make sure to use HW_NCPUONLINE instead of
> HW_NCPU
>
> You can pick through that list and compare the dates to the
> pledge/unveil adaptations commited into the tree.  It appears to move
> very rapidly, more rapidly than the average port.  The changes don't
> neccessarily make it into -stable and -stable packages, but *we never
> promised that*, and this specific pledge/unveil-using application is now
> using API that didn't exist in 6.6.
>
>> (I'm not criticizing -- I understand that ...
>
> Yes, you are are criticizing.  And with inaccurate statements.  And you
> are wrong about there being a lagg.  By telling the world the chromium
> openbsd effort is "slow", you are being an innaccurate downer.
>


-- 
David J. Raymond
david.raym...@nmt.edu
http://physics.nmt.edu/~raymond

Re: Iridium vs Chromium

[Theo de Raadt]

Elias M. Mariani  wrote:

> Actually, I was just checking the ports-changes mailing-list, and the
> sync between Iridium and Chromium made me ask this.

Step right up, step right up, there's room for volunteers

Re: Iridium vs Chromium

[Elias M. Mariani]

Actually, I was just checking the ports-changes mailing-list, and the
sync between Iridium and Chromium made me ask this.
In any case, OpenBSD ports has nothing to do with this question. I ask
here just because the OpenBSD community has a better view of this
things. And (so far) they had made interesting points when asking
about other things (Security Cameras for example).

> like the lagg is many months.
> are wrong about there being a lagg.  By telling the world the chromium
Is "lagg" different from "lag" or just a typo? Honest question.


On Sun, Apr 12, 2020 at 1:11 PM Theo de Raadt  wrote:
>
> Raymond, David  wrote:
>
> > That said, I am a bit nervous about OpenBSD's lags in
> > keeping up with browser security fixes.
>
> It isn't that simple.
>
> They don't ship security fixes standalone.  Instead, they ship a mix of
> new changes *and* fixes.  Lots of new unrelated changes, and only a few
> security fixes.  These fixes cannot be plausibly seperated out, as doing
> such a seperate procedure would increase the development workload, and
> increase the update lag.  So instead this software is accepted from mainstream
> on the assumption of their best effort, and then the following happens:
>
> The large changesets requires evaluation and verification, to ensure it
> still works with the pledge/unveil changes.  The pledge/unveil changes
> introduce a tighter sandbox than other operating systems have.  Quite
> often, upstream performs operations in the wrong order, and robert finds
> this out during test.  This friction slows the development a little.
>
> But I believe you are completely wrong about how long this lag is.
> You are being inaccurate because you don't know, and making it sound
> like the lagg is many months.
>
> 81.0.4044.92 came out 5 days ago, and here you can see it enter the ports
> tree 2 days ago.
>
> 1 hour ago it was replaced with a newer update.
>
> date: 2020/04/10 18:51:30;  author: robert
> update to 81.0.4044.92;
> date: 2020/04/03 13:44:40;  author: robert
> update to 80.0.3987.163
> date: 2020/04/01 12:32:05;  author: robert
> update to chromium-80.0.3987.162;
> date: 2020/03/21 14:08:01;  author: robert
> update to 80.0.3987.149 and apply the following changes:
> date: 2020/03/11 23:57:03;  author: espie
> date: 2020/03/04 15:44:17;  author: robert
> update to 80.0.3987.132 and fix the component flavor while here
> date: 2020/02/22 12:33:20;  author: robert
> update to 80.0.3987.116;
> date: 2020/01/17 20:43:38;  author: robert
> update to 79.0.3945.130
> date: 2020/01/08 14:43:32;  author: robert
> update to 79.0.3945.117
> date: 2019/12/18 09:01:35;  author: robert
> update to 79.0.3945.88
> date: 2019/12/15 12:03:46;  author: robert
> update to 79.0.3945.79
> date: 2019/11/20 18:26:30;  author: robert
> update to 78.0.3904.106
> date: 2019/11/07 10:47:41;  author: robert
> update to 78.0.3904.97
> date: 2019/11/05 22:30:26;  author: robert
> update to 78.0.3904.87
> date: 2019/10/22 18:35:43;  author: robert
> update to 77.0.3865.120 and make sure to use HW_NCPUONLINE instead of HW_NCPU
>
> You can pick through that list and compare the dates to the
> pledge/unveil adaptations commited into the tree.  It appears to move
> very rapidly, more rapidly than the average port.  The changes don't
> neccessarily make it into -stable and -stable packages, but *we never
> promised that*, and this specific pledge/unveil-using application is now
> using API that didn't exist in 6.6.
>
> > (I'm not criticizing -- I understand that ...
>
> Yes, you are are criticizing.  And with inaccurate statements.  And you
> are wrong about there being a lagg.  By telling the world the chromium
> openbsd effort is "slow", you are being an innaccurate downer.

Re: Iridium vs Chromium

[Theo de Raadt]

Raymond, David  wrote:

> That said, I am a bit nervous about OpenBSD's lags in
> keeping up with browser security fixes.

It isn't that simple.

They don't ship security fixes standalone.  Instead, they ship a mix of
new changes *and* fixes.  Lots of new unrelated changes, and only a few
security fixes.  These fixes cannot be plausibly seperated out, as doing
such a seperate procedure would increase the development workload, and
increase the update lag.  So instead this software is accepted from mainstream
on the assumption of their best effort, and then the following happens:

The large changesets requires evaluation and verification, to ensure it
still works with the pledge/unveil changes.  The pledge/unveil changes
introduce a tighter sandbox than other operating systems have.  Quite
often, upstream performs operations in the wrong order, and robert finds
this out during test.  This friction slows the development a little.

But I believe you are completely wrong about how long this lag is.
You are being inaccurate because you don't know, and making it sound
like the lagg is many months.

81.0.4044.92 came out 5 days ago, and here you can see it enter the ports
tree 2 days ago.  

1 hour ago it was replaced with a newer update.

date: 2020/04/10 18:51:30;  author: robert
update to 81.0.4044.92;
date: 2020/04/03 13:44:40;  author: robert
update to 80.0.3987.163
date: 2020/04/01 12:32:05;  author: robert
update to chromium-80.0.3987.162;
date: 2020/03/21 14:08:01;  author: robert
update to 80.0.3987.149 and apply the following changes:
date: 2020/03/11 23:57:03;  author: espie
date: 2020/03/04 15:44:17;  author: robert
update to 80.0.3987.132 and fix the component flavor while here
date: 2020/02/22 12:33:20;  author: robert
update to 80.0.3987.116;
date: 2020/01/17 20:43:38;  author: robert
update to 79.0.3945.130
date: 2020/01/08 14:43:32;  author: robert
update to 79.0.3945.117
date: 2019/12/18 09:01:35;  author: robert
update to 79.0.3945.88
date: 2019/12/15 12:03:46;  author: robert
update to 79.0.3945.79
date: 2019/11/20 18:26:30;  author: robert
update to 78.0.3904.106
date: 2019/11/07 10:47:41;  author: robert
update to 78.0.3904.97
date: 2019/11/05 22:30:26;  author: robert
update to 78.0.3904.87
date: 2019/10/22 18:35:43;  author: robert
update to 77.0.3865.120 and make sure to use HW_NCPUONLINE instead of HW_NCPU

You can pick through that list and compare the dates to the
pledge/unveil adaptations commited into the tree.  It appears to move
very rapidly, more rapidly than the average port.  The changes don't
neccessarily make it into -stable and -stable packages, but *we never
promised that*, and this specific pledge/unveil-using application is now
using API that didn't exist in 6.6.

> (I'm not criticizing -- I understand that ...

Yes, you are are criticizing.  And with inaccurate statements.  And you
are wrong about there being a lagg.  By telling the world the chromium
openbsd effort is "slow", you are being an innaccurate downer.

Re: Iridium vs Chromium

[Raymond, David]

My problem with iridium is that it is based on an older version of
chromium and I am not sure that they keep up with inevitable flow of
security fixes.  That said, I am a bit nervous about OpenBSD's lags in
keeping up with browser security fixes.  (I'm not criticizing -- I
understand that OpenBSD is a small operation without the people needed
to keep track of non-core packages.  And I just converted from Arch
Linux, in which the storm of updates and resulting incompatibilities
drove me crazy and contributed to my shift to OpenBSD.  Still, I am a
bit nervous about even slightly out-of-date browsers at this point and
I am not sure that iridium is an improvement in this regard.)

Dave

On 4/12/20, Elias M. Mariani  wrote:
> I'm not much of a browser savy guy.
> Is Iridium really safer than Chromium?
> Leaving aside the "Google is tracking you!".
>
> Any recommendations on the browser front on performance, security and
> compatibility?
> I've been using Chrome and Chromium for years, but maybe there are
> better alternatives that I'm unaware of...
>
> Cheers.
> Elias.
>
>


-- 
David J. Raymond
david.raym...@nmt.edu
http://physics.nmt.edu/~raymond

Re: i386 kernel relinking

[Josh Grosse]

FWIW, the GNU linker can reorder the kernel on i386-current
with 256MB RAM:

   # env LD=ld.bfd /usr/libexec/reorder_kernel

---

relink.log:

(SHA256) /bsd: OK
LD="ld.bfd" LDFLAGS="-g" sh makegap.sh 0x gapdummy.o
ld.bfd -T ld.script -X --warn-common -nopie -o newbsd ${SYSTEM_HEAD} vers.o 
${OBJS}
textdatabss dec hex
11916299262796  1101824 13280919caa697
mv newbsd newbsd.gdb
ctfstrip -S -o newbsd newbsd.gdb
rm -f bsd.gdb
mv -f newbsd bsd
install -F -m 700 bsd /bsd && sha256 -h /var/db/kernel.SHA256 /bsd

Kernel has been relinked and is active on next reboot.

SHA256 (/bsd) = 3c9cca9da06acdc92270f6f0e68b57447881a01e3e2584a0086291efb5033ba7

---

On Fri, Apr 10, 2020 at 10:52:37AM -0600, Theo de Raadt wrote:
> I am succesfully relinking kernels on a landisk with 128MB of ram.
> 
> I think this conversation is ridiculous:
> 
> If a machine is too small, then it is too small.  Do I have to paypal
> a $0.05 to some users?
> 
> Nick Holland  wrote:
> 
> > 
> > 
> > 
> > On 2020-04-10 10:10, Stefan Sperling wrote:
> > > On Fri, Apr 10, 2020 at 09:35:16AM -0400, Nick Holland wrote:
> > >> Question about kernel randomization and relinking...
> > >> 
> > >> It seems to take a fair amount of RAM, at least for systems that
> > >> are forced to run i386.  And I mean real RAM -- swap doesn't seem
> > >> to cut it.  
> > >> 
> > >> I discovered that several machines I was intending on using for
> > >> minimal purposes just couldn't complete relinking.  So I built a
> > >> VM and started playing with the RAM.
> > >> 
> > >> Built with 1G RAM, default was a 1.2G swap, worked fine.
> > >> Reduced to 256MB RAM, Kernel failed to relink.  As with my old
> > >> junk.
> > >>
> > >> The magic number seemed to be between 320MB (failed) and 384MB 
> > >> (worked) of RAM.  Ok, fine.  
> > > 
> > > FWIW, my soekris net5501 with 256MB of RAM and 512MB swap does manage
> > > to relink a kernel (on 6.6 + syspatches).
> > 
> > Whoops.  Guess I should have mentioned, that was -current, as of
> > yesterday 
> > OpenBSD 6.7-beta (GENERIC.MP) #110: Thu Apr  9 01:20:52 MDT 2020
> > dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
> > real mem  = 334970880 (319MB)
> > avail mem = 313077760 (298MB)
> > 
> > and probably a couple weeks ago for the real (old) hw.
> > 
> > I'm curious if your Soekris can handle 6.7-beta.
> > 
> > Nick.
> > 
> > 
> > > 
> > > # ls -l relink.log
> > > -rw-r--r--  1 root  wheel  -  507B Apr 10 13:33 relink.log
> > > # cat relink.log   
> > > (SHA256) /bsd: OK
> > > LD="ld" LDFLAGS="-g" sh makegap.sh 0x gapdummy.o
> > > ld -T ld.script -X --warn-common -nopie -o newbsd ${SYSTEM_HEAD} vers.o 
> > > ${OBJS}
> > > textdatabss dec hex
> > > 11815507267748  1101824 13185079c93037
> > > mv newbsd newbsd.gdb
> > > ctfstrip -S -o newbsd newbsd.gdb
> > > rm -f bsd.gdb
> > > mv -f newbsd bsd
> > > install -F -m 700 bsd /bsd && sha256 -h /var/db/kernel.SHA256 /bsd
> > > 
> > > Kernel has been relinked and is active on next reboot.
> > > 
> > > SHA256 (/bsd) = 
> > > a940ce989d708e5b87a1186ee81bd624066baeabe67b8405b52e4fa2988b565
> > > 
> > > 
> > > # dislabel -pm wd0
> > > #size   offset  fstype [fsize bsize   cpg]
> > >   a:   353.0M   64  4.2BSD   2048 16384  5624 # /
> > >   b:   511.1M   722944swap# none
> > >   c: 15280.0M0  unused
> > >   d:   444.8M  1769728  4.2BSD   2048 16384  7116 # /tmp
> > >   e:   607.7M  2680576  4.2BSD   2048 16384  9685 # /var
> > >   f:  1703.0M  3925216  4.2BSD   2048 16384 12958 # /usr
> > >   g:   505.8M  7412896  4.2BSD   2048 16384  8060 # 
> > > /usr/X11R6
> > >   h:  1632.9M  8448736  4.2BSD   2048 16384 12958 # 
> > > /usr/local
> > >   i:  1381.2M 11792960  4.2BSD   2048 16384 12958 # 
> > > /usr/src
> > >   j:  5282.4M 14621632  4.2BSD   2048 16384 12958 # 
> > > /usr/obj
> > >   k:  2850.9M 25439936  4.2BSD   2048 16384 12958 # /home
> > > 
> > 

Iridium vs Chromium

[Elias M. Mariani]

I'm not much of a browser savy guy.
Is Iridium really safer than Chromium?
Leaving aside the "Google is tracking you!".

Any recommendations on the browser front on performance, security and
compatibility?
I've been using Chrome and Chromium for years, but maybe there are
better alternatives that I'm unaware of...

Cheers.
Elias.

Re: Wine for OpenBSD?

[Ottavio Caruso]

On Sun, 12 Apr 2020 at 08:24, slackwaree  wrote:
>
> You don't want wine anyway. That is the shining example of badly written 
> software which sucked 15 years ago the same way it does today. T


Provided Wine is now broken on most modern OSes that only ship with
64-bit binaries, there are tons of reasons why Wine is still relevant.
There are gazillions of abandonware (badly) written for old versions
of Windows (Win 3.* up to XP) that don't even run properly on Windows
10 but run beautifully on Wine. I have to thank Wine for getting my
amateur licence because I had to run a multiple question trainer
written circa 2006. Not to mention countless old electrical/electronic
software that nobody is bothered porting to 64-bit *nix.

-- 
Ottavio Caruso

Re: Wine for OpenBSD?

[Radek]

On Sun, 12 Apr 2020 07:24:09 +
slackwaree  wrote:

> You don't want wine anyway. That is the shining example of badly written 
> software which sucked 15 years ago the same way it does today. They tried to 
> make it better with cedega, crossover office and what not and failed 
> miserably. All you could get out of it is to run basic apps like notepad or 
> calc even those with tons of bugs like borders, frames missing, broken fonts, 
> crashes etc. They claimed it can run game X,Y,Z but who cares about it when 
> Windows can run all games perfectly. This is ain't the 90's man everyone can 
> afford to have 2-3 or more PCs at home and with all these virtualization 
> supports like vmware, virtualbox around which just runs perfectly windows 
> applications in windows I even ask the question why is wine still exist, 
> probably it's someones pet project who don't want to let it go...
> 
> 
> 
> ‐‐‐ Original Message ‐‐‐
> On Saturday, April 11, 2020 12:15 PM, Nikita Stepanov 
>  wrote:
> 
> > Wine for OpenBSD?
> 
> 

> All you could get out of it is to run basic apps like notepad or calc even 
> those with tons of bugs like borders, frames missing, broken fonts, crashes 
> etc.
I used to have FreeBSD on my old office desktop till 2018, WINE was the only 
way to run MT4 [1] on it. MT4 worked flawlessly with WINE, no frames missing, 
no broken fonts, not even one crash for few years... 

> This is ain't the 90's man everyone can afford to have 2-3 or more PCs at 
> home 
But sometimes you have to be outside the home.

[1] https://www.metatrader4.com/

Cheers!
-- 
Radek

Re: Wine for OpenBSD?

[Strahil Nikolov]

On April 12, 2020 10:24:09 AM GMT+03:00, slackwaree  
wrote:
>You don't want wine anyway. That is the shining example of badly
>written software which sucked 15 years ago the same way it does today.
>They tried to make it better with cedega, crossover office and what not
>and failed miserably. All you could get out of it is to run basic apps
>like notepad or calc even those with tons of bugs like borders, frames
>missing, broken fonts, crashes etc. They claimed it can run game X,Y,Z
>but who cares about it when Windows can run all games perfectly. This
>is ain't the 90's man everyone can afford to have 2-3 or more PCs at
>home and with all these virtualization supports like vmware, virtualbox
>around which just runs perfectly windows applications in windows I even
>ask the question why is wine still exist, probably it's someones pet
>project who don't want to let it go...
>
>
>
>‐‐‐ Original Message ‐‐‐
>On Saturday, April 11, 2020 12:15 PM, Nikita Stepanov
> wrote:
>
>> Wine for OpenBSD?

Nah... Some people (like me) doesn't want to have windows at all.

Sadly, karma is a b**ch and now I got a Win VM :)
Yet, you won't need windows just to run a single app occasionally.

I don't claim that wine is great, but it is useful .

For me porting WINE to the BSD family is not worth it and utterly useless.

On the other side  ZFS is a more reasonable approach and if anyone asks -  I 
think that openBSD can securely host VMs and in such use - ZFS or LVM can be 
quite useful.

Best Regards,
Strahil Nikolov

openbsd.org down?

[Salvatore Cuzzilla]

Can’t reach openbsd.org  - planned maintenance?

Re: Wine for OpenBSD?

[slackwaree]

You don't want wine anyway. That is the shining example of badly written 
software which sucked 15 years ago the same way it does today. They tried to 
make it better with cedega, crossover office and what not and failed miserably. 
All you could get out of it is to run basic apps like notepad or calc even 
those with tons of bugs like borders, frames missing, broken fonts, crashes 
etc. They claimed it can run game X,Y,Z but who cares about it when Windows can 
run all games perfectly. This is ain't the 90's man everyone can afford to have 
2-3 or more PCs at home and with all these virtualization supports like vmware, 
virtualbox around which just runs perfectly windows applications in windows I 
even ask the question why is wine still exist, probably it's someones pet 
project who don't want to let it go...



‐‐‐ Original Message ‐‐‐
On Saturday, April 11, 2020 12:15 PM, Nikita Stepanov 
 wrote:

> Wine for OpenBSD?