OpenBSD's model and philosophy match both my requirements and expectations
perfectly, Theo. I'm just not too fond of stuff unexpectedly breaking -
admittedly because I missed out on this specific thread -, but for which
Stuart's tip is an excellent mitigation indeed.
Kind regards,
Dirk
--
Stuart Henderson wrote:
> On 2020/05/19 14:23, Dirk Praet wrote:
> > A manual xorg config with the vesa driver brought X back to life, but not
> > until I set machdep.allowaperture=2 in /etc/sysctl.conf . Thanks for your
> > reply, Matthieu. I do hope 6.7 doesn't come with similar surprises,
On 2020/05/19 14:23, Dirk Praet wrote:
> A manual xorg config with the vesa driver brought X back to life, but not
> until I set machdep.allowaperture=2 in /etc/sysctl.conf . Thanks for your
> reply, Matthieu. I do hope 6.7 doesn't come with similar surprises, though
Run -current between
A manual xorg config with the vesa driver brought X back to life, but not
until I set machdep.allowaperture=2 in /etc/sysctl.conf . Thanks for your
reply, Matthieu. I do hope 6.7 doesn't come with similar surprises, though
--
Sent from:
On Mon, May 11, 2020 at 09:40:30AM -0700, Dirk Praet wrote:
> Hi Matthieu,
>
> It would seem I'm a bit (too) late to this party. In short: I'm running a
> high security environment leveraging the combined power of contemporary
> OpenBSD and ancient i386 hardware stuffed with RAM, but untouched by
Touché.
I should probably rephrase this as "operating a slightly less insecure
environment as compared to running vanilla Windows 10 on contemporary COTS
hardware". And finding it really hard to throw away perfectly good hardware
that suited the intended purposes really well until Matthieu
Dirk Praet wrote:
> Hi Matthieu,
>
> It would seem I'm a bit (too) late to this party. In short: I'm running a
> high security environment leveraging the combined power of contemporary
^
> OpenBSD and ancient i386 hardware stuffed with RAM, but untouched by all
Hi Matthieu,
It would seem I'm a bit (too) late to this party. In short: I'm running a
high security environment leveraging the combined power of contemporary
OpenBSD and ancient i386 hardware stuffed with RAM, but untouched by all
kinds of modern BIOS/EFI/processor "management" technology. My
On Mon, Apr 22, 2019 at 06:47:23PM +0200, Matthieu Herrb wrote:
> Hi,
>
> In xenocara, we still build a number of video drivers for very old
> hardware, that is mostly useless. For AGP, I don't have a working
> motherboard to test the cards I still have.
> I also still have a few PCI cards for
On Tue, 23 Apr 2019 11:55:01 +0200 Matthieu Herrb wrote:
> If you are actually running X, ...
Not on the old "S3 Trio3D AGP" Pentium II 350MHz machines Matthieu,
(these are used as small servers, some with VGA glass tube screens).
> This is an Intel chipset supported by the current DRM
On Tue, Apr 23, 2019 at 10:28:18AM +0100, Craig Skinner wrote:
> On Mon, 22 Apr 2019 18:47:23 +0200 Matthieu Herrb wrote:
> > If you're still using a machine with a graphics card supported by one
> > of these, please speak up, otherwise they are going to be removed:
>
> Is this a valid way to
On Mon, 22 Apr 2019 18:47:23 +0200 Matthieu Herrb wrote:
> If you're still using a machine with a graphics card supported by one
> of these, please speak up, otherwise they are going to be removed:
Is this a valid way to find out Matthieu?
$ grep -i -e vga -e video /var/run/dmesg.boot
vga1 at
(sorry this isn't coming with In-Reply-To/References headers as I
read Matthieu's post on marc.info via Mastodon)
> So rather that try to blindly fix the issues with these drivers I'd
> rather remove them. This is the list of candidates for removing.
>
> If you're still using a machine with a
Hi,
In xenocara, we still build a number of video drivers for very old
hardware, that is mostly useless. For AGP, I don't have a working
motherboard to test the cards I still have.
I also still have a few PCI cards for some of them, but most of them
are dead, or don't work as primary display with
14 matches
Mail list logo
