Los Angeles Double Dedicated Debian / FreeBSD Shell Accounts from MetalVPS

Not_Oles · February 2024

@Not_Oles said: Set to cancel in a month, unless cancellation is revoked.

Looks like these two servers will cancel on the 26th. Only six days more.

A good chance to play with FreeBSD or Debian 12 in Los Angeles, if anybody is interested.

Here, the FreeBSD kernel is actually running on the hardware, so it's not like the typical cloud BSD instance, where BSD runs on Qemu, which is runniing on Linux, which is running on the hardware.

Currently there is only one other guy plus me on each of these servers. I'm happy because I have learned a lot and had a lot of fun. So, for me, it's certainly been worth what I spent. Thanks also to @Average4552 for his financial support and very fun participation!

I thought another LETizen or even a few more might have wanted to join. Well, maybe we could take a couple more guys for the few days which remain. Also, I'm not against continuing past the expiration of the current contract period, but I think I would want to move over to Psychz directly, cuz then we could have IPv6 support without needing TunnelBroker.

Average4552 · February 2024

I don't really know anything about BSD. What's different about it vs. Linux? What can you do with it better than you can with a Linux distro?

Not_Oles · February 2024

@Average4552 said:
I don't really know anything about BSD. What's different about it vs. Linux? What can you do with it better than you can with a Linux distro?

Well, I don't really know anything about BSD either. I guess the usual answer is that some people think BSD gives higher performance in some situations. I watched a Youtube video presentation where an engineer from Netflix discussed in some detail the changes Netflix implimented in the FreeBSD kernel and the fabulous throughput that Netflix gets from FreeBSD. Probably some people believe that OpenBSD gives great security, perhaps at the cost of some performance.

In my own limited experience, most everything on BSD is easier to get working than other OSes because BSD almost always just works out of the box. Additionally, as a group, the BSD folks seem very helpful and very knowledgeable. Same with the Slackware folks, though that's a Linux which looks a little like BSD.

It's quite a different experience to log into BSD and look around. Many fewer processes running. Good integration between the kernel and the userland base.

I think it's fun to try various OSes. I'm lucky now! As an old guy, I don't have to actually accomplish anything any more. So I am free to play around.

The last few days I have been messing with the elvis text editor. I don't personally know anybody who uses elvis any more. Maybe one guy who is a slacker, because elvis is the default editor on Slackware. Did you know that, per Reference 10 in the linked Wikipedia article, nvi was based on elvis?

elvis is so, so old fashioned compared to VSCode! A long time ago I had a lot of fun making a little website with elvis. elvis has the capability to switch back and forth between html code and the same code as rendered. (For a subset of old html code. And elvis doesn't have UTF-8.) I haven't used elvis for years. I just thought it might be fun to spin up elvis and use it again for a moment.

A few weeks ago I compiled the old, old TWM window manager on Fedora Rawhide. Same motivation, a lot of fun! Rawhide doesn't have a package for TWM any more, so I had to compile it.

I am wondering how much work it would be to add UTF-8 to elvis. I don't know the answer yet, but I am learning a little bit more about makefiles and C libraries. I am wondering about whether elvis plus tools like htmx and maybe htmz still might be able to accomplish something useful in 2024.

One of my servers in Germany has been running Fedora Rawhide for months and months. Maybe it's been a year? That server gets hundreds of updates almost every day. It successfully compiled three different versions of elvis, and a lot of other software too, and that's with brand new versions of gcc and the GNU C library. It's hard for me to say that anything works better than Feedora. Or Debian. Or Alpine. FreeBSD's build tooling is very different from default Fedora, though. FreeBSD uses clang and BSD libc.

I hope you have a lot of fun too! Best wishes!

Not_Oles · February 2024

@Not_Oles said:
I heard that the missing library might be part of the X Window System. One option might be to install X and thus hopefully obtain the missing library. Alternatively, set a configure option to disable X in elvis.

From the Makefile:

################################################################################
# This macro gives any arguments which will be needed during linking.
# Mostly, this means "-Llibdir" and "-llib" flags.  If you're compiling with
# X-windows support, then you'll have to add a "-lX11" and maybe a
# "-L/usr/X11/lib" flag or something similar.
LIBS=  -lipc -ltermcap 

################################################################################
# This should be "unix" for all UNIX variants.  It causes the compiler to use
# files from the osunix subdirectory, and do a UNIX-style installation.
OS=unix
root@deviceXXXX:~/src/elvis-2.2_1/elvis-2.2_1 # ls /usr/X11
ls: /usr/X11: No such file or directory
root@deviceXXXX:~/src/elvis-2.2_1/elvis-2.2_1 #

Hmm. Following the instructions in the FreeBSD Handbook at https://docs.freebsd.org/en/books/handbook/x11/, I installed xorg. But, even though quite a bit was installed, at least at first glance, installing xorg didn't seem to get me the -lipc library that ld doesn't find. Could -lipc be part of an older version of xorg or maybe xfree86? I might just try recompiling to see what happens, and then look around a little more before possibly trying to compile elvis without X.

chronos@penguin:~/servers/oneprovider/XXXX$ wc -l freebsd-install-xorg-20240220 
822 freebsd-install-xorg-20240220
chronos@penguin:~/servers/oneprovider/XXXX$ grep ipc freebsd-install-xorg-20240220 
chronos@penguin:~/servers/oneprovider/XXXX$

Not_Oles · February 2024

@Not_Oles said: I watched a Youtube video presentation where an engineer from Netflix discussed in some detail the changes Netflix implimented in the FreeBSD kernel and the fabulous throughput that Netflix gets from FreeBSD.

I think this might have been the video: Drew Gallatin of Netflix on FreeBSD optimizations used by Netflix serving at 800Gb/s - Drew Gallatin - EuroBSDcon 2022.

FreeBSD.org has the presentation slides. Here's the discussion at HN.

tmntwitw · February 2024

@Not_Oles said:
The last few days I have been messing with the elvis text editor. I don't personally know anybody who uses elvis any more. Maybe one guy who is a slacker, because elvis is the default editor on Slackware. Did you know that, per Reference 10 in the linked Wikipedia article, nvi was based on elvis?

Thanks for sharing the information about elvis! I'm still using elvis on some of my Slackware VMs. It was the default editor on Slackware prior to 15.0.

nvi replaced elvis as the default editor on Slackware 15.0, but elvis is still available though.

From Slackware 15.0 changelog:

a/nvi-1.81.6-x86_64-1.txz: Added.
       This is an implementation of the classic ex/vi text editor written by Keith
       Bostic. Due to this having UTF8 support which elvis lacks, we'll have it
       take over the ex/vi symlinks if they aren't already pointing to a different
       choice. Note that the removal of vi/ex symlinks from the elvis and vim
       packages might cause your ex/vi symlinks to point to this after all the ex/vi
       packages have been upgraded. You can set them to your preferences using
       pkgtool -> Setup -> vi-ex.

Not_Oles · February 2024

@tmntwitw! Thanks for letting me know! It's the end of an Era!

Not_Oles · February 2024

@Not_Oles said: installing xorg didn't seem to get me the -lipc library that ld doesn't find. Could -lipc be part of an older version of xorg or maybe xfree86?

Here's a comment that Google found in https://goma.googlesource.com/wine/+/307b3c8ed59acf2de2a049d27b5784a6a97733e6/configure :

9787 # BSDI BSD/OS 2.1 needs -lipc for XOpenDisplay.

Looks like this -lipc might be pretty old! But maybe it's a hint to look at XOpenDisplay.

I bet we have somebody here who knows all about this! Is there some easy way for me to get -lipc so that elvis will compile with X? Or do I need to try compiling without X support?

Not_Oles · February 2024

Even after configure with the "--without-x" option, the linker still wants -lipc.

cc -O -Iosunix main.o osblock.o osdir.o osprg.o ostext.o osnet.o optglob.o options.o safe.o session.o buffer.o calc.o color.o descr.o digraph.o display.o gui.o lowbuf.o mark.o misc.o io.o dmhex.o dmmarkup.o dmnormal.o dmsyntax.o scan.o tcaphelp.o autocmd.o cut.o draw.o event.o ex.o exaction.o exconfig.o exedit.o exmake.o exsubst.o fold.o ftp.o http.o input.o lp.o map.o message.o move.o more.o need.o operator.o regexp.o region.o regsub.o search.o spell.o state.o tinytcap.o tag.o tagsrch.o tagelvis.o url.o vi.o vicmd.o window.o  guix11.o xclip.o xevent.o xmisc.o xscroll.o xstatus.o xtext.o xtool.o xdialog.o guicurs.o guitcap.o guiopen.o lpescape.o lpovrtyp.o lpps.o -lipc -ltermcap -o elvis
ld: error: unable to find library -lipc
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** Error code 1

Stop.
make: stopped in /root/src/elvis-2.2_1/elvis-2.2_1

What happens if the "-lipc" is removed from the linker command?

root@deviceXXXX:~/src/elvis-2.2_1/elvis-2.2_1 # cc -O -Iosunix main.o osblock.o osdir.o osprg.o ostext.o osnet.o optglob.o options.o safe.o session.o buffer.o calc.o color.o descr.o digraph.o display.o gui.o lowbuf.o mark.o misc.o io.o dmhex.o dmmarkup.o dmnormal.o dmsyntax.o scan.o tcaphelp.o autocmd.o cut.o draw.o event.o ex.o exaction.o exconfig.o exedit.o exmake.o exsubst.o fold.o ftp.o http.o input.o lp.o map.o message.o move.o more.o need.o operator.o regexp.o region.o regsub.o search.o spell.o state.o tinytcap.o tag.o tagsrch.o tagelvis.o url.o vi.o vicmd.o window.o  guix11.o xclip.o xevent.o xmisc.o xscroll.o xstatus.o xtext.o xtool.o xdialog.o guicurs.o guitcap.o guiopen.o lpescape.o lpovrtyp.o lpps.o -ltermcap -o elvis
root@deviceXXXX:~/src/elvis-2.2_1/elvis-2.2_1 #

We get an elvis binary which at least launches and runs a shell command.

root@deviceXXXX:~/src/elvis-2.2_1/elvis-2.2_1 # ls -l elvis
-rwxr-xr-x  1 root 100 587920 Feb 21 19:55 elvis
root@deviceXXXX:~/src/elvis-2.2_1/elvis-2.2_1 # ./elvis

~                                                                                                 
~                                                                                                                                                                                              ~                                                                                                                                                                                             ~                                                                                                                                                                                              ~                                                                                                                                                                                       
~                                                                                                 
~                                                                                                 
~                                                                                                 
~                                                                                                 
~                                                                                                 
~                                                                                                 
~                                                                                                 
~                                                                                                 
~                                                                                                 
~                                                                                                 
~   
:!date                                                                              
Wed Feb 21 20:04:41 UTC 2024
Hit <Enter> to continue

tmntwitw · February 2024

@Not_Oles said:
Even after configure with the "--without-x" option, the linker still wants -lipc.

I am guessing it might be that they missed out adding the [$GUI_X11" = "define" ] condition for the freebsd case statement at the configure script, which might be why "-lipc" still gets processed even though "--without-x" is specified.

The original case statement at the configure script:

  *freebsd*)
        why "For FreeBSD, we ignore the <sys/select.h> file"
        NEED_SELECT_H="undef"
        who "   To support X11, it also requires -lipc"
        XLIBS=" -lipc"
        ;;

If the [ "$GUI_X11" = "define" ] condition is added to the case statement:

  *freebsd*)
        why "For FreeBSD, we ignore the <sys/select.h> file"
        NEED_SELECT_H="undef"
        if [ "$GUI_X11" = "define" ]
        then
          who "   To support X11, it also requires -lipc"
          XLIBS=" -lipc"
        fi
        ;;

We get an elvis binary which at least launches and runs a shell command.

Congrats on getting a working elvis binary!

tmntwitw · February 2024

@Not_Oles said:
I am wondering how much work it would be to add UTF-8 to elvis.

This thread might be of some relevance: https://github.com/mbert/elvis/issues/13

Not_Oles · February 2024

Hi @tmntwitw!

Thanks for your very helpful comments!

So far I've tried compiling three versions of elvis:

elvis-2.2 and
elvis-almost-2.2_1 from Steve Kirkendall, and also
the third party elvis from mbert.

All of these versions seem to compile cleanly on Fedora Rawhide. elvis-2.2 from Kirkendall compiles cleanly on FreeBSD 14.0-RELEASE. We're talking here in this thread about compiling Kirkendall's elvis-almost-2.2_1 on FreeBSD 14.0-RELEASE. I haven't tried the mbert elvis on FreeBSD yet because, haha, I got stuck on the almost-2.2_1.

Probably NetBSD pkgsrc has a version of elvis which will compile cleanly almost everywhere, but I haven't tried elvis from pkgsrc yet.

Yes, I saw the Github issue you linked concerning UTF-8 in the mbert repo. I have not much experience with C. The approach taken in the Github issue discussion seemed to use K&R types which are larger than char to hold the UTF-8 characters. But newer versions of C introduced wide character types. I don't know enough yet to decide which version of C I would want to use. Maybe K&R would be best. I guess, although I am not sure, another approach might be to try to rewrite just the core of elvis in a later version of C and then add features later. Other than the linked Github issue, I've not yet found and read anything specifically on the topic of adding UTF-8 to pre-UTF-8 C code.

Are you experienced in how to do stuff like adding UTF-8 to old C code?

Thanks again! I'm grateful for your comments!

Tom

Not_Oles · February 2024

Google found a multibyte nvi2! Maybe I can figure out a little about these guys did the multibyte conversion.

root@deviceXXXX:~/src # git clone https://github.com/lichray/nvi2.git
Cloning into 'nvi2'...
remote: Enumerating objects: 4119, done.
remote: Counting objects: 100% (127/127), done.
remote: Compressing objects: 100% (81/81), done.
remote: Total 4119 (delta 60), reused 95 (delta 43), pack-reused 3992
Receiving objects: 100% (4119/4119), 1.53 MiB | 3.49 MiB/s, done.
Resolving deltas: 100% (2866/2866), done.
root@device7469:~/src # cd nvi2
root@device7469:~/src/nvi2 # ls
.git            INSTALL.md      catalog         ex              regex
.gitignore      LICENSE         cl              files           vi
CMakeLists.txt  README          common          man
root@deviceXXXX:~/src/nvi2 # ls common/
args.h          delete.c        key.h           mark.h          options.c       screen.h
common.h        encoding.c      line.c          mem.h           options.h       search.c
conv.c          exf.c           log.c           msg.c           options_f.c     seq.c
conv.h          exf.h           log.h           msg.h           put.c           seq.h
cut.c           gs.h            main.c          multibyte.h     recover.c       util.c
cut.h           key.c           mark.c          options.awk     screen.c        util.h
root@deviceXXXX:~/src/nvi2 #

Edit to add: https://lists.freebsd.org/pipermail/freebsd-hackers/2011-August/036096.html

Not_Oles · February 2024

The wide character support in nvi2 seems to have been added to nvi as a Google Summer of Code project using a library from NetBSD called libiconv.

The original proposal for the nvi wide character project is on archive.org at https://web.archive.org/web/20111005031226/https://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/zy/1

I learned about the iconv command. Running iconv -l lists all the character encodings supported by your libiconv. I ran icov -l on both FreeBSD and Linux. It's amazing how many character encodings are supported!

So now we know one way to add wide character support: libiconv.

I noticed that nvi2 doesn't seem to be the default nvi on our FreeBSD 14.0-RELEASE machine.

root@deviceXXXX:~ # which nvi2
nvi2: Command not found.
root@deviceXXXX:~ #

If I fire up nvi in FreeBSD and type ": ve" and press Enter, I get

Version 2.2.0 (2020-08-01) The CSRG, University of California, Berkeley.

How come nvi2seems not to have made it into the FreeBSD default base system? There are additional ways of adding wide character support, some of which are mentioned in the Existing Solutions section of the above linked GSoC proposal. man nvi on our FreeBSD 14.0-RELEASE doesn't seem to explain the supported character encodings. But nvi Version 2.2.0 does display some emojis, such as "🗽🇺🇸🇲🇽🏜️".

Howdy, Stranger!

Categories

In this Discussion

Los Angeles Double Dedicated Debian / FreeBSD Shell Accounts from MetalVPS

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

Los Angeles Double Dedicated Debian / FreeBSD Shell Accounts from MetalVPS

Comments