> On Mar 23, 2019, at 7:50 AM, Maxime Villard wrote:
>
> Here is a patch [1] that untangles the dependency. Cross-compile-tested on
> alpha from amd64.
>
> [1] https://m00nbsd.net/garbage/compat/alpha.diff
This patch looks fine to me.
-- thorpej
Le 24/03/2019 à 00:41, Thor Lancelot Simon a écrit :
On Sun, Mar 17, 2019 at 05:41:18AM +0800, Paul Goyette wrote:
On Sat, 16 Mar 2019, Maxime Villard wrote:
Regarding COMPAT_OSF1: I'm not totally sure, but it seems that Alpha's
COMPAT_LINUX uses COMPAT_OSF1 as dependency (even if there is no
On Sun, Mar 17, 2019 at 05:41:18AM +0800, Paul Goyette wrote:
> On Sat, 16 Mar 2019, Maxime Villard wrote:
>
> > Regarding COMPAT_OSF1: I'm not totally sure, but it seems that Alpha's
> > COMPAT_LINUX uses COMPAT_OSF1 as dependency (even if there is no proper
> > dependency in the module),
Le 16/03/2019 à 22:41, Paul Goyette a écrit :
On Sat, 16 Mar 2019, Maxime Villard wrote:
Regarding COMPAT_OSF1: I'm not totally sure, but it seems that Alpha's
COMPAT_LINUX uses COMPAT_OSF1 as dependency (even if there is no proper
dependency in the module), because there are osf1_* calls.
On Sat, Mar 16, 2019 at 10:09:19PM -0400, Mouse wrote:
> Even if I had a working VAX (which I
> don't; for all that I care about it, caring alone does not make it
> practical for me to run mine), the Project would not be interested in
> my suggestions unless they fit within its "`industrially
I think I used it once, but did not need it.Well said Jason.
-Original Message-
From: Jason Thorpe
To: Bob Smith
Cc: Dave McGuire ; Maxime Villard ;
Tech-kern ; port-pmax ; port-alpha
Sent: Sat, Mar 16, 2019 8:32 pm
Subject: Re: Regarding the ULTRIX and OSF1 compats
> On Mar
I'm quite annoyed to hear the complaints about the VAX compiler
situation. Many people have put in a lot of work to keep it functional
with newer versions of GCC, and to fix bugs.
The complaints seem to come from people who haven't even tried newer
versions of NetBSD. I've heard from a good
> Although your comment about the practically of actually using one of these m$
Maybe when they were new. But I have at least a half-dozen that I
picked up for free when others were dumping them as useless because
they had nothing left using AUI Ethernet. Perhaps they were less
common where you
> The NetBSD project even publicly states on the ports page (https://www.netbs$
No, it's not. But they also publicly state that it is the problem of
the port's people to keep it working, even when the problem is caused
by someone doing something to MI code that ends up breaking the
second-class
On Sat, Mar 16, 2019 at 12:36:17PM +0100, Maxime Villard wrote:
> Le 16/03/2019 ? 12:17, Robert Elz a ?crit :
> > If there are bug reports that are not being attended to (open PRs),
> > that's different. Otherwise unmaintained code is simply code that
> > doesn't need changes (which for
> To which my response is, then state this openly and clearly. And
> then people can decide if they want to run NetBSD or if they should
> look elsewhere.
Or elsewhen, perhaps, such as back to historical NetBSD. There's a
reason I still run 1.4T on my SPARCstations. (Okay, my semi-private
>> True as far as it goes. But if there is no Ultrix ABI for SPARC,
>> there is nothing to map.
> I think you are deliberately missing the point.
Missing the point? Perhaps. But not deliberately.
> the ultric compat layer does stuff like alter structure contents for
> some calls, alter ioctl
> On Mar 16, 2019, at 2:49 PM, Bob Smith wrote:
>
> As a list member for as long as this list has been around, and beta tester
> for the Vax versions in the 90s I think, (Hey Bilquist!,Mouse) and alpha
> versions,
> I can attest to Dave's knowledge. His head works rather well.
Indeed, I
> On Mar 16, 2019, at 3:14 PM, Maxime Villard wrote:
>
> Yes. Most of these functions are basic wrappers, that I think we can just
> gather into a linux_misc.c or similar.
Yes, that's the right thing to do, but note it's alpha-specific, and not shared
with other platforms' COMPAT_LINUX.
>
Date:Sat, 16 Mar 2019 22:05:33 +0100
From:Michael Kronsteiner
Message-ID: <876ba60fc91e02428e66f0b289d88af95a8f5a8e.ca...@gmx.at>
| not native.
OK, but that doesn't really matter.
| But if you're running a 64-bit version of Windows (and you probably
| are),
Le 16/03/2019 à 22:41, Paul Goyette a écrit :
On Sat, 16 Mar 2019, Maxime Villard wrote:
Regarding COMPAT_OSF1: I'm not totally sure, but it seems that Alpha's
COMPAT_LINUX uses COMPAT_OSF1 as dependency (even if there is no proper
dependency in the module), because there are osf1_* calls. Some
On 3/16/19 3:16 PM, Jason Thorpe wrote:
>> Ahh, the old saw of "time marches on", used everywhere for decades by
>> insecure people to justify trashing everything that came before them.
>
> Oh, come on... that's not really fair at all.
Jason I'm sorry that you feel that way, but I really
On 3/16/19 5:16 PM, Jonathan Stone wrote:
>> though your comment about the practically of
>> actually using one of these machines is telling ... [...]
>
>
> Anyone got a DEFTA they'd donate/long-term loan?
TurboChannel FDDI? I can send you one.
> On Mar 16, 2019, at 10:31 AM, Dave McGuire wrote:
>
> Ahh, the old saw of "time marches on", used everywhere for decades by
> insecure people to justify trashing everything that came before them.
Oh, come on... that's not really fair at all.
-- thorpej
On Sat, 16 Mar 2019, Maxime Villard wrote:
Regarding COMPAT_OSF1: I'm not totally sure, but it seems that Alpha's
COMPAT_LINUX uses COMPAT_OSF1 as dependency (even if there is no proper
dependency in the module), because there are osf1_* calls. Some more
compat mess to untangle, it seems...
In
On Sat, 3/16/19, Jason Thorpe wrote:
Subject: Re: Regarding the ULTRIX and OSF1 compats
To: "Jonathan Stone"
Cc: "Jaromír Doleček" , "Robert Elz"
, "Maxime Villard" , "Tech-kern"
, port-p...@netbsd.org, port-al...@netbsd.org
Date: Saturda
On March 16, 2019 5:02:46 PM Maxime Villard wrote:
> Le 16/03/2019 à 17:44, Dave McGuire a écrit :
>> On 3/16/19 11:04 AM, Maxime Villard wrote:
I think that what Robert, and others (including me) argument is
actually that things should not be removed, and the reason would be
that
> recognise the need for backward compat ... even Windows still runs
> ancient
> dos applications.
>
> kre
>
not native.
Windows 64-bit
But if you’re running a 64-bit version of Windows (and you probably
are), you’ll need a program that can run DOS in a virtual machine
inside
Windows.
Le 16/03/2019 à 20:49, m...@netbsd.org a écrit :
It makes me compelled to delete more of it.
COMPAT_LINUX doesn't work without matching PAGE_SIZE.
What does that mean?
On Sat, 16 Mar 2019, Maxime Villard wrote:
Anyway, people, let's wrap it up. The status right now is that I've disabled
COMPAT_OSF1 on Alpha, and I'm not sure if there is an improper dependency of
COMPAT_LINUX on COMPAT_OSF1, because I see calls like osf1_sys_wait4 in
Le 16/03/2019 à 17:44, Dave McGuire a écrit :
On 3/16/19 11:04 AM, Maxime Villard wrote:
I think that what Robert, and others (including me) argument is
actually that things should not be removed, and the reason would be
that this is the core mission, purpose, reason (or whatever you want
to
>
> You are obviously quite obsessed with chopping out functionality
> that
> you have unilaterally decided is not worth having in NetBSD anymore.
>
functionality...??? yes. works great. give it a try.
> Just who the hell do you think you are, anyway, and why are you so
> obsessed with
On 3/16/19 11:04 AM, Maxime Villard wrote:
>> I think that what Robert, and others (including me) argument is
>> actually that things should not be removed, and the reason would be
>> that this is the core mission, purpose, reason (or whatever you want
>> to call it) for NetBSDs existence. Instead
On 2019-03-16 20:11, Jason Thorpe wrote:
On Mar 16, 2019, at 11:29 AM, Johnny Billquist wrote:
As for me personally, yes, I am certainly guilty of mostly making noise, and
few contributions. I used to do a bit more, but mostly on VAX specific stuff.
But since other were making changes all
It makes me compelled to delete more of it.
COMPAT_LINUX doesn't work without matching PAGE_SIZE.
> On Mar 16, 2019, at 11:09 AM, Jonathan Stone wrote:
>
> Testing is a real issue. Anyone want to host a pmax or three?I could be
> persuaded to fire one up for specific testing, but it'll take a couple of
> weekends, maybe more. (It's been years since I had thinwire (BNC)
>
Hello all,
I don't see anyone asking to keep COMPAT_OSF1. It was never useful enough to
run "real" (arbitrary) OSF/1 binaries.
Please just remove it, and remove "and OSF1" from the Subject: line.
COMPAT_ULTRIX, is complete enough to run commercial apps; vendor X-servers for
all
> On Mar 16, 2019, at 11:29 AM, Johnny Billquist wrote:
>
> On 2019-03-16 19:25, Jason Thorpe wrote:
>>> On Mar 16, 2019, at 6:43 AM, Johnny Billquist wrote:
>>>
>>> Make it work - don't remove it.
>> That's rich. With some of the things we're talking about, "make it work"
>> (or "keep it
On 2019-03-16 19:59, Robert Elz wrote:
Date:Sat, 16 Mar 2019 16:53:16 +0100
From:Maxime Villard
Message-ID: <7acc19dd-9f66-f825-d517-6e7013de1...@m00nbsd.net>
| if they don't subscribe, it's their problem,
Really? Is that the same attitude you have
Date:Sat, 16 Mar 2019 16:53:16 +0100
From:Maxime Villard
Message-ID: <7acc19dd-9f66-f825-d517-6e7013de1...@m00nbsd.net>
| a) Yes the bug was in COMPAT_ULTRIX, which was found recently to have been
| used by _one_ person,
One that we know of. Where
On 3/16/19 11:53 AM, Maxime Villard wrote:
> I believe there is actually a strong cultural difference at play in e).
> To me,
> I perceive what you said in e) as something totally awful and crappy, that
> will dissuade every skilled developer from working on NetBSD because
> they can't
> even
On 2019-03-16 19:25, Jason Thorpe wrote:
On Mar 16, 2019, at 6:43 AM, Johnny Billquist wrote:
Make it work - don't remove it.
That's rich. With some of the things we're talking about, "make it work" (or "keep
it working") is a very resource-intensive proposition.
Hey, I have an idea...
Picking a random message in this thread to respond to.
FreeBSD has struggled with deprecation as well (which is what this is).
I'm working on a doc to help there, but the basic criteria are:
1. What is the cost to keep it. Include the API change tax here.
2. What is the benefit the project gets
> On Mar 16, 2019, at 6:43 AM, Johnny Billquist wrote:
>
> Make it work - don't remove it.
That's rich. With some of the things we're talking about, "make it work" (or
"keep it working") is a very resource-intensive proposition.
Hey, I have an idea... since you care so much about it, why
Date:Sat, 16 Mar 2019 12:01:04 -0400 (EDT)
From:Mouse
Message-ID: <201903161601.maa05...@stone.rodents-montreal.org>
| True as far as it goes. But if there is no Ultrix ABI for SPARC, there
| is nothing to map.
I think you are deliberately missing the point.
> e) "Tedious process" Yes, what you're talking about is a very
> tedious process, that will take literally _decades_ before we
> move forward and drop code [...]
Decades? Probably not. A decade? Mayyybe. Years? Certainly. And I
think that's how it should be. I am paid to use
On 2019-03-16 17:01, Mouse wrote:
[...]
It's a little like the modern mania for cross-building. It helps, but
only if you/we don't forget that it's only a rough approximation. How
long was it VAX was broken because there was something wrong that
showed up on native builds but not
> On Mar 16, 2019, at 9:09 AM, Maxime Villard wrote:
> Anyway, people, let's wrap it up. The status right now is that I've disabled
> COMPAT_OSF1 on Alpha, and I'm not sure if there is an improper dependency of
> COMPAT_LINUX on COMPAT_OSF1, because I see calls like osf1_sys_wait4 in
>
Le 16/03/2019 à 17:00, Jason Thorpe a écrit :
On Mar 16, 2019, at 5:09 AM, m...@netbsd.org wrote:
Most likely, COMPAT_ULTRIX and COMPAT_OSF1 have the same type of bugs
that we have seen in compatibility layers elsewhere.
Is it worth his time to test them?
Folks, PLEASE. This is a point I've
> On Mar 16, 2019, at 7:12 AM, Mouse wrote:
>
>> (or even is necessarily from an architecture that would ever normally
>> want that compat option - so we could include COMPAT_ULTRIX on a
>> sparc or x86_64 for testing purposes.)
>
> That borders on meaningless. If Ultrix never ran on SPARC
> On Mar 16, 2019, at 5:37 AM, Michael Kronsteiner wrote:
>
> for the time being - if i need an ultrix or osf(dec unix, tru64...)
> setup, i will install exactly that.
I'll use Ultrix as an example...
Perhaps you don't have any working Ultrix install media, or hard drives, etc.
But you
>> That borders on meaningless. If Ultrix never ran on SPARC or x86_64
>> (which was the case AFAIK), what would it even mean to be compatible
>> with it?
> It doesn't mean anything - that's not the point. The point is that
> these compat options are retained because people have old binaries
>
> On Mar 16, 2019, at 5:09 AM, m...@netbsd.org wrote:
>
> Most likely, COMPAT_ULTRIX and COMPAT_OSF1 have the same type of bugs
> that we have seen in compatibility layers elsewhere.
> Is it worth his time to test them?
Folks, PLEASE. This is a point I've tried to make repeatedly...
These
Le 16/03/2019 à 16:12, Robert Elz a écrit :
Date:Sat, 16 Mar 2019 14:28:27 +0100
From:Maxime Villard
Message-ID: <17ba7752-793d-d352-09ef-c43676d2f...@m00nbsd.net>
| Ok. So you believe that dead wood should hold back all of the development
| process?
No,
Date:Sat, 16 Mar 2019 13:37:10 +0100
From:Michael Kronsteiner
Message-ID:
| i see. would YOU run software that costs maybe 4-digit numbers for
| yearly license on an OS that "maybe" runs it "somehow" ?
I have done it, yes, back when I was at the University of
Le sam. 16 mars 2019 à 16:12, Robert Elz a écrit :
> Sorry, I must have missed that. All I ever seem to see is that xxx is
> unmaintained and full of unspecified bugs, and that obviously no-one cares,
> and so we should delete it.That's not an argument for anything.
You suggest that there
Date:Sat, 16 Mar 2019 10:12:20 -0400 (EDT)
From:Mouse
Message-ID: <201903161412.kaa07...@stone.rodents-montreal.org>
| That borders on meaningless. If Ultrix never ran on SPARC or x86_64
| (which was the case AFAIK), what would it even mean to be compatible
|
Date:Sat, 16 Mar 2019 14:28:27 +0100
From:Maxime Villard
Message-ID: <17ba7752-793d-d352-09ef-c43676d2f...@m00nbsd.net>
| Ok. So you believe that dead wood should hold back all of the development
| process?
No, but only if it truly is dead. Just because you
Le 16/03/2019 à 14:43, Johnny Billquist a écrit :
On 2019-03-16 14:28, Maxime Villard wrote:
I stated my point clearly and logically, about why certain things have
legitimate reasons to go away, regardless of whether they are compat layers,
or drivers, or something else. Rather than giving
>> I understand this point. But to me it is deeply wrong: the compat
>> layers use system APIs, and these APIs do change regularly.
> Whoever is changing them should be fixing all the users of those
> APIs, including the ones in the compat code.
Ideally, yes.
But I doubt that _any_ of the
> would YOU run software that costs maybe 4-digit numbers for yearly
> license on an OS that "maybe" runs it "somehow" ?
Well, _I_ wouldn't run it at all; I don't run software that has onerous
licenses. But I can easily imagine circumstances where someone with
such a license would want to.
On 2019-03-16 14:28, Maxime Villard wrote:
I stated my point clearly and logically, about why certain things have
legitimate reasons to go away, regardless of whether they are compat
layers,
or drivers, or something else. Rather than giving clear, logical counter
arguments, you are just
Le 16/03/2019 à 13:53, Robert Elz a écrit :
Whoever is changing them should be fixing all the users of those APIs,
including the ones in the compat code. Consider all the work PaulG
did as part of the kenel module changes recently -- that's an example of
how it should be done. Simply
>
> Well, if we want to talk reality - why are you even looking at
> NetBSD.
> Reality, business wise, is Linux. You might possibly argue FreeBSD.
> NetBSD is not an option, and will never become an option.
>
>Johnny
>
not yet. but im keeping an eye on it just because it runs on so many
On 2019-03-16 13:37, Michael Kronsteiner wrote:
On Sat, 2019-03-16 at 18:17 +0700, Robert Elz wrote:
Date:Sat, 16 Mar 2019 09:45:07 +0100
From:Maxime Villard
Message-ID:
NetBSD can support newer hardware at the OS level, and old userland,
which doesn't care
On Sat, 2019-03-16 at 18:17 +0700, Robert Elz wrote:
> Date:Sat, 16 Mar 2019 09:45:07 +0100
> From:Maxime Villard
> Message-ID:
>
>
> NetBSD can support newer hardware at the OS level, and old userland,
> which doesn't care what the hardware underneath is in any
maxv cares deeply for netbsd's security and has found multiple bugs in
syscall emulation layers. So he took part in creating tools that
mechanize the work of finding them, KASLR, KLEAK. But they need to
run the code to find bugs.
Most likely, COMPAT_ULTRIX and COMPAT_OSF1 have the same type of
Le 16/03/2019 à 10:12, Johnny Billquist a écrit :
On 2019-03-16 09:45, Maxime Villard wrote:
Le 16/03/2019 à 06:23, John Nemeth a écrit :
On Mar 15, 10:31pm, Michael Kronsteiner wrote:
}
} i have this discussion today aswell... considering 64/32bit machines.
} if you want ultrix, install
On 2019-03-16 09:45, Maxime Villard wrote:
Le 16/03/2019 à 06:23, John Nemeth a écrit :
On Mar 15, 10:31pm, Michael Kronsteiner wrote:
}
} i have this discussion today aswell... considering 64/32bit machines.
} if you want ultrix, install ultrix. if you want osf1/dec unix/tru64
} install that.
On 2019-03-16 11:50, Maxime Villard wrote:
Le 16/03/2019 à 11:26, Johnny Billquist a écrit :
If the answer is that we remove the code, then indeed, the whole
webpage is
incorrect, and we should change it to state that we do not try to be
interoperable, implementing many standard APIs, or care
Le 16/03/2019 à 12:17, Robert Elz a écrit :
If there are bug reports that are not being attended to (open PRs),
that's different. Otherwise unmaintained code is simply code that
doesn't need changes (which for emulation of ancient systems is not
a huge surprise - those systems aren't changing
Date:Sat, 16 Mar 2019 09:45:07 +0100
From:Maxime Villard
Message-ID:
| > Emulating other systems is fundamental to what NetBSD is about.
|
| This is a really simplistic answer. It is not difficult to see that our
| website does not reflect reality at all.
Le 16/03/2019 à 11:26, Johnny Billquist a écrit :
If the answer is that we remove the code, then indeed, the whole webpage is
incorrect, and we should change it to state that we do not try to be
interoperable, implementing many standard APIs, or care about other platforms.
There seems to be
On 2019-03-16 10:24, Maxime Villard wrote:
Le 16/03/2019 à 10:12, Johnny Billquist a écrit :
On 2019-03-16 09:45, Maxime Villard wrote:
Le 16/03/2019 à 06:23, John Nemeth a écrit :
By any chance, have you seen our About page:
http://www.netbsd.org/about/ ? The second paragraph reads
On Mar 15, 10:31pm, Michael Kronsteiner wrote:
}
} i have this discussion today aswell... considering 64/32bit machines.
} if you want ultrix, install ultrix. if you want osf1/dec unix/tru64
} install that. being able to run ummm nearly 20 year old binaries...
} well. if thats what you want be
> In the case of Ultrix, you don't even need the old system to run
> Ultrix binaries, because IIRC, they're all statically-
> linked. There's already been one example of "ability to run
> commercial software for Ultrix" posted in this thread, and we should
> let that keep working (believe it or
Le 10/03/2019 à 17:39, Maxime Villard a écrit :
There's been more emphasis on the fact that COMPAT_OSF1 should go. Do people
have anything to say about that?
So, no one? I will remove it soon...
i have this discussion today aswell... considering 64/32bit machines.
if you want ultrix, install ultrix. if you want osf1/dec unix/tru64
install that. being able to run ummm nearly 20 year old binaries...
well. if thats what you want be prepared for a ride. i never ran
"foreign" binaries on a
> On Mar 15, 2019, at 2:31 PM, Michael Kronsteiner wrote:
>
> i have this discussion today aswell... considering 64/32bit machines.
> if you want ultrix, install ultrix. if you want osf1/dec unix/tru64
> install that. being able to run ummm nearly 20 year old binaries...
> well. if thats
> On Mar 15, 2019, at 1:57 PM, Maxime Villard wrote:
>
> Le 10/03/2019 à 17:39, Maxime Villard a écrit :
>> There's been more emphasis on the fact that COMPAT_OSF1 should go. Do people
>> have anything to say about that?
>
> So, no one? I will remove it soon...
Bonne chance, COMPAT_OSF1.
Please read _*all*_ the answers, because I've already said that I was fine
with keeping COMPAT_ULTRIX. If someone has been able to even run a full
ULTRIX userland, then it's probably functional enough, and we can keep it
for the time being. Case closed.
On Mar 10, 12:16pm, Maxime Villard wrote:
} Le 10/03/2019 à 11:25, Björn Johannesson a écrit :
} >
} > COMPAT_ULTRIX (mips) works fine which I recently discovered after shuffling
} > some disks and NetBSD8 mounted the ULTRIX disk as /
}
} This more likely means that it was an old UFS disk that
> On Mar 10, 2019, at 4:16 AM, Maxime Villard wrote:
>
> Le 10/03/2019 à 11:25, Björn Johannesson a écrit :
>> Hello.
>>
>> COMPAT_ULTRIX (mips) works fine which I recently discovered after shuffling
>> some disks and NetBSD8 mounted the ULTRIX disk as /
>
> This more likely means that it
Le 10/03/2019 à 13:30, Björn Johannesson a écrit :
>This more likely means that it was an old UFS disk that we do support by
>default in our UFS/FFS code, but I hardly seehow this could be related to
COMPAT_ULTRIX.
What I meant was that it mounted the ULTRIX root disk and proceeded to run
Hello.
COMPAT_ULTRIX (mips) works fine which I recently discovered after shuffling
some disks
and NetBSD8 mounted the ULTRIX disk as /
Not that I have terribly much use for it (except maybe maple) but I would still
like it to be kept in.
/B
Hello.
On Sun, 3/10/19, Maxime Villard wrote:
Subject: Re: Regarding the ULTRIX and OSF1 compats
To: "Björn Johannesson" , tech-kern@netbsd.org
Cc: port-p...@netbsd.org, port-al...@netbsd.org
Date: Sunday, March 10, 2019, 12:16 PM
Le
Le 10/03/2019 à 11:25, Björn Johannesson a écrit :
Hello.
COMPAT_ULTRIX (mips) works fine which I recently discovered after shuffling
some disks and NetBSD8 mounted the ULTRIX disk as /
This more likely means that it was an old UFS disk that we do support by
default in our UFS/FFS code, but I
Le 09/03/2019 à 18:58, Jason Thorpe a écrit :
On Mar 9, 2019, at 8:22 AM, Maxime Villard wrote:
New thread, CC'ed to port-pmax@ and port-alpha@, in the continuity of:
https://mail-index.netbsd.org/tech-kern/2019/03/09/msg024754.html
Basically, there were talks about retiring
Ever since seeing Hubbard & co’s “NextBSD” stuff I’ve been hoping that Mach
would eventually find its way into the BSDs. For all its warts there’s enormous
utility in Mach’s primitives, both IPC and other. (Of course I’m also a
NeXT/Apple/Darwin person, so I’m used to building on them…)
—
> On Mar 9, 2019, at 10:59 AM, Chris Hanson wrote:
>
> Ever since seeing Hubbard & co’s “NextBSD” stuff I’ve been hoping that Mach
> would eventually find its way into the BSDs. For all its warts there’s
> enormous utility in Mach’s primitives, both IPC and other. (Of course I’m
> also a
> On Mar 9, 2019, at 8:22 AM, Maxime Villard wrote:
>
> New thread, CC'ed to port-pmax@ and port-alpha@, in the continuity of:
>
> https://mail-index.netbsd.org/tech-kern/2019/03/09/msg024754.html
>
> Basically, there were talks about retiring COMPAT_ULTRIX and COMPAT_OSF1,
> because
New thread, CC'ed to port-pmax@ and port-alpha@, in the continuity of:
https://mail-index.netbsd.org/tech-kern/2019/03/09/msg024754.html
Basically, there were talks about retiring COMPAT_ULTRIX and COMPAT_OSF1,
because they are of questionable utility, in addition to being clear dead
87 matches
Mail list logo
