Portable OpenBSD vi for Unix systems(github.com)
github.com
Portable OpenBSD vi for Unix systems
https://github.com/johnsonjh/OpenVi
28 comments
> I wish they were catalogued somewhere, like an "awesome list".
Sure, they are listed here
https://github.com/ligurio/awesome-openbsd#portable-openbsd-...
Sure, they are listed here
https://github.com/ligurio/awesome-openbsd#portable-openbsd-...
Haha, this is exactly what I asked for. :-) I should have checked Awesome OpenBSD. Thanks for making this list.
FYI the doas ports you added are poorly maintained.
The nholstein repo clearly states: This repository temporarily unmaintained.
And the slicer69 project has had some insecure code added in the past: https://xn--1xa.duncano.de/slicer69-doas.html
The awesome-openbsd repo only links to the Duncaen OpenDoas repo: https://github.com/Duncaen/OpenDoas
The nholstein repo clearly states: This repository temporarily unmaintained.
And the slicer69 project has had some insecure code added in the past: https://xn--1xa.duncano.de/slicer69-doas.html
The awesome-openbsd repo only links to the Duncaen OpenDoas repo: https://github.com/Duncaen/OpenDoas
Sorry, I meant to link to https://github.com/Duncaen/OpenDoas instead of https://github.com/nholstein/OpenDoas. Thank you for correcting my mistake.
> the slicer69 project has had some insecure code added in the past
Ouch... surely no distribution would package this garbage, right?
Ouch... surely no distribution would package this garbage, right?
What is so difficult in porting ? OpenBSD is a (duck) UNIX so it shouldn't be any issue.
It's really just the effort and time to understand the data structures and API considerations between the two systems. Saying something is a UNIX doesn't absolve you of the duty of knowing how the specific UNIX was implemented. Also, Linux has no UNIX heritage so relying on UNIX knowledge isn't as helpful as you might think and most of the commonalities are through things like POSIX standards which don't necessarily drive kernel internals directly. If the application relies on a specific kernel features, you might have a very complicated or impossible task ahead.
Also, OpenBSD really doesn't have a huge install base. It's a fairly niche project and the people that work on it really don't care about Linux at all. You'd have to find someone with the skills to be able to translate between the two, the time to do it, and the desire to do it. I have the skills and most of the desire but not the time otherwise I'd be working on projects like this. I've been getting pretty sick of the Linux eco-sphere for a while now so it'd be nice to have some saner production tools. Unfortunately I have to have a day job and no one at work even knows about OpenBSD.
Also, OpenBSD really doesn't have a huge install base. It's a fairly niche project and the people that work on it really don't care about Linux at all. You'd have to find someone with the skills to be able to translate between the two, the time to do it, and the desire to do it. I have the skills and most of the desire but not the time otherwise I'd be working on projects like this. I've been getting pretty sick of the Linux eco-sphere for a while now so it'd be nice to have some saner production tools. Unfortunately I have to have a day job and no one at work even knows about OpenBSD.
> It's a fairly niche project and the people that work on it really don't care about Linux at all.
Maybe true for the core OS, but they provide portable OpenSSH, OpenSMTPD, OpenNTPD, LibreSSL and a few others.
Maybe true for the core OS, but they provide portable OpenSSH, OpenSMTPD, OpenNTPD, LibreSSL and a few others.
I started with Bell Labs Unix, transitioned through many variations, and then when I came to OpenBSD and Linux, they were both pretty straightforward compared with, say, porting to or from System V Unix.
I don't think you're wrong about anything. It's true that one may need to pore over kernel code, and yes, often you have the "duty of knowing how the specific Unix was implemented". I just that that you're over-emphasizing the difficulty.
Life is hard (including programming), but that's where we calibrate our zero setting.
I don't think you're wrong about anything. It's true that one may need to pore over kernel code, and yes, often you have the "duty of knowing how the specific Unix was implemented". I just that that you're over-emphasizing the difficulty.
Life is hard (including programming), but that's where we calibrate our zero setting.
I'm also increasingly sick of the Linux eco-sphere these days. I think there is something to be said in favor of Linux ditching POSIX and other standards and that this inclination has definitely had some positives and pushed us forward further than we may have gone otherwise in some areas.
But I don't think a total lack of a standard was what should have replaced Unix standardization efforts.
I think my real issue with Linux is that it is increasingly complicated (both the kernel and most distributions). It doesn't feel as "open source" as some of the not even quite open source Unix's, because you need to be a domain expert in a particular area for you to be able to modify it correctly. When you've got a team of people responsible for the whole OS as a single package, there is some incentive to keep your area maintainable. You never know who is going to be switching teams or knocking on your door. With Linux the incentive structure is to make a name for yourself as "the <particular subsystem or utility program> guy", which opens up a lot of potential for feature creep and overengineering.
But I don't think a total lack of a standard was what should have replaced Unix standardization efforts.
I think my real issue with Linux is that it is increasingly complicated (both the kernel and most distributions). It doesn't feel as "open source" as some of the not even quite open source Unix's, because you need to be a domain expert in a particular area for you to be able to modify it correctly. When you've got a team of people responsible for the whole OS as a single package, there is some incentive to keep your area maintainable. You never know who is going to be switching teams or knocking on your door. With Linux the incentive structure is to make a name for yourself as "the <particular subsystem or utility program> guy", which opens up a lot of potential for feature creep and overengineering.
As someone moving back and forth between BSDs and Linux over the years. I think I can relate to this feeling.
On Linux you inarguably have more options in terms of software, higher performance, better device driver support, etc. But even when you participate on the level of a distribution you still have the feeling that many components are at times poorly understood by your fellow developers (do not get me wrong though, I have plenty of respect for them) and that the direction for many parts that are essential to you is made elsewhere.
On the contrary, on the BSDs you get a spectrum of pragmatism, idealism, goals, etc. under a single roof. As I was younger I also found it hard to understand how limited the scope of say OpenBSD was in that they would not care about certain use cases: "You want to play the latest games? Why not get a Windows desktop or a console?! Now let me get back to try to figure out how to handle the insanity of locales, while keeping the code complexity from not going through the roof!". Perhaps it was some sort of "replace Windows with a single solution" drive inside of me? Not that "Linux users use Linux because they hate Windows. BSD users use BSD because they love Unix." is necessarily always true, but as I grow older I believe I can see better what it is hinting at.
I do not think I can say that one is better than the other in some sort of absolute truth sense. However, I can say that personally I tend to enjoy the BSD world much more as a user and (limited) contributor. I am willing to make the sacrifices and rethink my software dependencies and what hardware I can use, not because it makes me better than others, but because I enjoy the understanding of the software I rely on and tight community that comes with it.
Unrelated, andomdeazzz662, we seem to have vouched you back into the world of mortals. But do note the comment I made earlier [1].
[1]: https://news.ycombinator.com/item?id=37290633
On Linux you inarguably have more options in terms of software, higher performance, better device driver support, etc. But even when you participate on the level of a distribution you still have the feeling that many components are at times poorly understood by your fellow developers (do not get me wrong though, I have plenty of respect for them) and that the direction for many parts that are essential to you is made elsewhere.
On the contrary, on the BSDs you get a spectrum of pragmatism, idealism, goals, etc. under a single roof. As I was younger I also found it hard to understand how limited the scope of say OpenBSD was in that they would not care about certain use cases: "You want to play the latest games? Why not get a Windows desktop or a console?! Now let me get back to try to figure out how to handle the insanity of locales, while keeping the code complexity from not going through the roof!". Perhaps it was some sort of "replace Windows with a single solution" drive inside of me? Not that "Linux users use Linux because they hate Windows. BSD users use BSD because they love Unix." is necessarily always true, but as I grow older I believe I can see better what it is hinting at.
I do not think I can say that one is better than the other in some sort of absolute truth sense. However, I can say that personally I tend to enjoy the BSD world much more as a user and (limited) contributor. I am willing to make the sacrifices and rethink my software dependencies and what hardware I can use, not because it makes me better than others, but because I enjoy the understanding of the software I rely on and tight community that comes with it.
Unrelated, andomdeazzz662, we seem to have vouched you back into the world of mortals. But do note the comment I made earlier [1].
[1]: https://news.ycombinator.com/item?id=37290633
Hijacking a reply here to notify andomdeazzz662 [1] who made a sibling comment. You appear shadow banned to me and I am not entirely sure why. I have vouched for your comment on this submission and the other two you made related to IBM's new chip [2], but it seems like I did not have the power to get you out of the shadow realm. There are cases where shadow banning is justified, but to my eye you are contributing to both discussions.
[1]: https://news.ycombinator.com/user?id=andomdeazzz662
[2]: https://news.ycombinator.com/item?id=37281851
[1]: https://news.ycombinator.com/user?id=andomdeazzz662
[2]: https://news.ycombinator.com/item?id=37281851
Openbsd has some security related syscalls not present in say Linux and FreeBSD.
I'll be able to try a bit later, but does it handle UTF-8 correctly? I remember having some versions of nvi split characters through the middle when doing e.g. folding back in the day.
EDIT: Sorry, I'm a dum-dum, it's written in the README:
> No support for Unicode / UTF-8 / wide character display
> Multibyte support is planned, but is unfortunately non-trivial, […]
EDIT: Sorry, I'm a dum-dum, it's written in the README:
> No support for Unicode / UTF-8 / wide character display
> Multibyte support is planned, but is unfortunately non-trivial, […]
You mean to tell me vi from the 1970s doesn't support LSP? This is an outrage!
Ok, you're joking, but still, are you referring to the 1987 Liskov Substitution Principle? https://en.wikipedia.org/wiki/Liskov_substitution_principle
Language Server Protocol - https://langserver.org
Thank you; that does make more sense.
Most OpenBSD users with Unicode needs will use nvi2 from ports.
[deleted]
[deleted]
I would love to see portable OpenBSD cron. Features like random ranges with steps (https://undeadly.org/cgi?action=article;sid=20230507122935) and `-s` (https://man.openbsd.org/OpenBSD-7.2/crontab.5#s) put it ahead of almost every other. It could replace many uses of systemd timers on Linux.
Edit: Added doas ports.