Live data from Hacker News

This is my attempt to get Vulkan going on NetBSD

github.com

31–40 of 40 posts

Re: This is my attempt to get Vulkan going on NetBSD

#31
post #8

Installation instructions: ftp https://raw.githubusercontent.com/segaboy/vulkan-netbsd/main/scripts/setup-env.sh !^^^^^! That's... a bit unorthodox. FreeBSD has a `fetch`[1] utility for this, I wasn't aware NetBSD puts that in `ftp`[2]. Interesting choice. I wonder what led to it. [1] https://man.freebsd.org/cgi/man.cgi?fetch [2] https://man.netbsd.org/ftp.1

I dunno, that feels very BSD to me. Presumably, they had a ftp utility first, and then when somebody wanted to download files over http they looked around and decided that the obvious thing to do was to add it to the existing file transfer/download program. Same as continuing to add functions to ifconfig rather than inventing a new ip tool.

Sure, if those functions added were related to configuring network interfaces, but it would be odd if someone added functions for configuring storage controllers.

Re: This is my attempt to get Vulkan going on NetBSD

#32

Earlier quoted context omitted.

Technically, it isn't wrong, if you consider Vulkan the technology rather than the service

isn't Vulkan the api?

'Vulkan' can refer to at least:

- Vulkan as a runtime service: 'the ability' for programs to do Vulkan things

- Vulkan as an API / specification: how programs interact with the service to do those things, or how the service interacts with programs

- Vulkan as a technology: how the API calls are implemented

Generally Vulkan refers to the specification much like how Linux refers to the kernel, but there is still Linux (kernel) vs Linux (syscall ABI) vs Linux (runtime service)

Re: This is my attempt to get Vulkan going on NetBSD

#33
post #8

Installation instructions: ftp https://raw.githubusercontent.com/segaboy/vulkan-netbsd/main/scripts/setup-env.sh !^^^^^! That's... a bit unorthodox. FreeBSD has a `fetch`[1] utility for this, I wasn't aware NetBSD puts that in `ftp`[2]. Interesting choice. I wonder what led to it. [1] https://man.freebsd.org/cgi/man.cgi?fetch [2] https://man.netbsd.org/ftp.1

Actually, it's orthodox; and it's fetch that isn't. FreeBSD is actually the odd one out, for having an extra tool for doing the same thing. The ftp tool in all of the BSDs, including FreeBSD, speaks HTTP, and has done since Luke Mewburn did lukemftp (later to be named tnftp) and Theo de Raadt did likewise, both based on the original 4.2BSD ftp, back in the middle 1990s.

* https://cgit.freebsd.org/src/tree/contrib/tnftp/ChangeLog#n1...

* https://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/ftp/main.c?...

* https://cvsweb.openbsd.org/log/src/usr.bin/ftp/main.c,v?sort...

Re: This is my attempt to get Vulkan going on NetBSD

#34

Earlier quoted context omitted.

this is what i would recommend. hoist it over from freebsd. it works well vulkan is fully usable, mesa works nicely. Even seen people playing with CUDA tho i didnt get that workin myself yey.

FreeBSD relies on being able to run the Linux graphics drivers though via a compat layer.

NetBSD uses the Linux graphics drivers too.

Re: This is my attempt to get Vulkan going on NetBSD

#36
post #33
post #8

Installation instructions: ftp https://raw.githubusercontent.com/segaboy/vulkan-netbsd/main/scripts/setup-env.sh !^^^^^! That's... a bit unorthodox. FreeBSD has a `fetch`[1] utility for this, I wasn't aware NetBSD puts that in `ftp`[2]. Interesting choice. I wonder what led to it. [1] https://man.freebsd.org/cgi/man.cgi?fetch [2] https://man.netbsd.org/ftp.1

Actually, it's orthodox; and it's fetch that isn't. FreeBSD is actually the odd one out, for having an extra tool for doing the same thing. The ftp tool in all of the BSDs, including FreeBSD, speaks HTTP, and has done since Luke Mewburn did lukemftp (later to be named tnftp) and Theo de Raadt did likewise, both based on the original 4.2BSD ftp, back in the middle 1990s. * https://cgit.freebsd.org/src/tree/contrib/tnf…

Nice! Thank you, that explains it. FreeBSD was my first *BSD and the only one I had long-term contact with, so I unconsciously use it as my "BSD standard". My bad on that :)

Re: This is my attempt to get Vulkan going on NetBSD

#37

Earlier quoted context omitted.

I dunno, that feels very BSD to me. Presumably, they had a ftp utility first, and then when somebody wanted to download files over http they looked around and decided that the obvious thing to do was to add it to the existing file transfer/download program. Same as continuing to add functions to ifconfig rather than inventing a new ip tool.

Sure, if those functions added were related to configuring network interfaces, but it would be odd if someone added functions for configuring storage controllers.

Imagine using an ftp program to transfer files.

Re: This is my attempt to get Vulkan going on NetBSD

#38
The vulkan stack is rather lean (there are still c++ though, valve removed a lot of c++ for less c++, it would have been correct with plain and simple C).

The big chunk is DRM kernel code.

AMD seems to be working on _userland_ hardware command ring buffers, which should makes userland vulkan even simpler. Dunno how they will work around the VMID stuff though.

Re: This is my attempt to get Vulkan going on NetBSD

#39
post #37

Earlier quoted context omitted.

Sure, if those functions added were related to configuring network interfaces, but it would be odd if someone added functions for configuring storage controllers.

Imagine using an ftp program to transfer files.

BitTorrent transfers files, so should a BT client be bolted on too? Typically the Unix philosophy has been do one thing well, not do all the things.

Re: This is my attempt to get Vulkan going on NetBSD

#40
post #37

Earlier quoted context omitted.

Imagine using an ftp program to transfer files.

BitTorrent transfers files, so should a BT client be bolted on too? Typically the Unix philosophy has been do one thing well, not do all the things.

The sticking point is always what "one thing" is. I can certainly see an argument for "download a file over http" (or, for another program, ftp), but I can also see an argument for "download files over the internet". In which case, honestly the only reason I'd even quirk an eyebrow at a BSD's ftp(1) adding bittorrent support is that bittorrent usually means running a daemon that that does feel out of character for it. But even then I wouldn't be that surprised to see it added.
Post reply on HN