Please wait...
2023-07-26 23:57 from Nurb432 <nurb432@uncensored.citadel.org>
Subject: Re: X = X ?
You forfeit one punch in your geek card :)
Can I earn it back if my excuse is that I spend the vast majority of my computing time in a terminal and not looking at fancy pictures?
Can I earn it back if my excuse is that I spend the vast majority of
my computing time in a terminal and not looking at fancy pictures?
Only if it is actually an actual dumb terminal sitting on your desk, and not a terminal program. If you are running a terminal program, you are running it on X (or Wayland) and you forfeit a punch in your geek card. If you are running a terminal program on Windows or Mac OS, you forfeit several punches in your geek card.
I've got a Wyse 150 gathering dust in the garage ... if I had a larger office I'd take it out and hook it up to my main computer. Maybe it would be usable for programming if I got it into 132 column mode.
I am emmeowing on a new server project. I am building a storage
server. Looking at getting a new Adaptec HBA card. The HBA
1200-32i that can attach up to 32 drives, and it supports mixed-mode
32 connectors on one card ... yowza
I've built a few like that, and you're making a lot of good choices:
* Separate boot drive (this is actually the one place I'd still use hardware disk mirroring)
* Software "raid"
* No partitioning
Some people really freak out at that last one. But why bother with partitions when your volume manager or multi disk filesystem can do it for you? Some people say "if there is no partition table then you have no way of knowing the disk is in use" but I think those people deserve to lose their data.
This is especially true with virtual machines because the host's virtual disk manager *is* your volume manager. My typical layout goes something like this:
* Disk 0: GPT with an EFI partition (because the ROM insists on it; can't go raw with EFI partition)
* Disk 1: swap (raw on the disk)
* Disk 2: root (raw on the disk)
If root needs to get bigger, you just make the virtual disk bigger and resize it. If you want dedicated filesystems, they go on dedicated virtual disks.
No fuss, no muss.
It actually has 2 connectors for disks. You get cables that connect to these, and the cables have 16 SAS/SATA connectors on the other ends.
I'm thinking the pool setup will be as follows:
zroot -> NVMe
litterbox -> massive storage array
most datasets will be on zroot, since FreeBSD ... but /usr/home will be on litterbox. A number of stuff on my laptop is also going to get moved over to the litterbox, like all the stuff for IRIX and MacOS 8. Then I'll be able to disable NFS and AFP on my laptop.
Thu Jul 27 2023 19:20:20 EDT from IGnatius T Foobar32 connectors on one card ... yowza
I've built a few like that, and you're making a lot of good choices:
* Separate boot drive (this is actually the one place I'd still use hardware disk mirroring)
* Software "raid"
* No partitioning
Some people really freak out at that last one. But why bother with partitions when your volume manager or multi disk filesystem can do it for you? Some people say "if there is no partition table then you have no way of knowing the disk is in use" but I think those people deserve to lose their data.
This is especially true with virtual machines because the host's virtual disk manager *is* your volume manager. My typical layout goes something like this:
* Disk 0: GPT with an EFI partition (because the ROM insists on it; can't go raw with EFI partition)
* Disk 1: swap (raw on the disk)
* Disk 2: root (raw on the disk)
If root needs to get bigger, you just make the virtual disk bigger and resize it. If you want dedicated filesystems, they go on dedicated virtual disks.
No fuss, no muss.
All of the g-drive and one-drive people really missed out on that.
I don't have a /home on my machine. I used to have it, it was a symlink to /usr/home. I have since deleted it.
Tue Aug 01 2023 17:52:58 EDT from IGnatius T FoobarAh, the old tradition of sharing /home across every machine, keeping your data right there at your fingertips without resorting to silly replication tricks.
All of the g-drive and one-drive people really missed out on that.
Ok, so the old tradition of sharing the home directory hierarchy across every machine.
Better?
For a while, i had my home directories pointed to a single NFS share ( like we are talking about ) BUT the share was physically an external drive hanging off the NAS server.. So worse case i could yank it and take it with me.
But as time went on, i stopped using more than one machine that needed 'all the stuff' ( for various reasons ).. So that went away and a simple weekly backup of my directory in case my main machine catches fire is good enough.,
Since FreeBSD 6.x, teh default place for home folders is /usr/home, and /home has been a symlink to /usr/home.
Also, because I am ancient, I remember when home directories would be in /usr/username rather than /home/username or /usr/home/username or wherever else they put them now. I cut my teeth on Xenix in the early 1980s. Ugghhh.
Also for a while they would put home directories in /u/username to separate them from the rest of the /usr hierarchy.
I think the original point of /usr was that you could mount it read-only and/or have it shared between multiple machines. Most of this is lost to history at this point, but at least we've never had to deal with drive letters.
I had forgot about that. Ya i did that too in some cases to avoid installing the same exact things on several boxes.
Then some fool came out with /opt....
Wed Aug 02 2023 05:23:27 PM EDT from IGnatius T Foobar
I think the original point of /usr was that you could mount it read-only and/or have it shared between multiple machines.
Then some fool came out with /opt....
WTF is supposed to go in /opt anyway? I've occasionally come across systems where someone has installed a large package there (e.g. /opt/octave) but it seems incredibly rare. Does proprietary software put stuff there?
For that matter, WTF goes in /srv? At one point we had a Java servlet that wanted its config files to live elsewhere, and I put them in /srv/<application> to keep them separate from the system config files in /etc. I was then furnished with a proper sized cluebat with which to whack myself (size XXL) and realized that, duh, /etc is really the right place after all. So now /srv sits empty again.
WTF is supposed to go in /opt anyway? I've occasionally come across
systems where someone has installed a large package there (e.g.
/opt/octave) but it seems incredibly rare. Does proprietary software
put stuff there?
/opt is the dumpster where you put applications that can't be fit easyly elsewhere. For example, if some application is distributed as a statically linked tarball that includes a whole clusterfuck of proprietary libraries, you cannot place the libraries in their corresponding locations, then place the main binary in /usr/local/bin and have it call them... so you dump the whole trball in /opt/sucker_application cand call it a day.
According to both the System V Application Binary Interface and the Linux Filesystem Hierarchy specification, "/opt" is for "add-on application software packages". The /opt hierarchy is notably missing from FreeBSD.
I don't see any purpose for /opt having been added, when /usr/local already existed and was doing just fine. The only thing I can think of is that they wanted to put it somewhere else because, as previously mentioned, /usr is supposed to be read-only.
There is some merit to keeping programs installed by the system administrator separate from programs installed as part of the operating system distribution.
But with package managers ... not a LOT of merit. And with installable software moving towards fully-encapsulated sandbox packages, it will begin to matter even less.
Anyway, just from the way I've seen it used, I always got the impression that /opt is for software or packages that aren't built and installed locally (that's what /usr/local is for), and aren't distributed with the OS or through a package manager.
The best example I can think of off the top of my head is Adobe Acrobat Reader as published by Adobe. You download binaries from Adobe, those should be installed in /opt.
Not to derail but I had a lot of fun with ATA over Ethernet - what sort of similar offerings are current?
iSCSI is kinda the industry standard. It's SCSI over IP. Both Target (server) and Initiator (client) mode are supported in FreeBSD base.
Speaking of FreeBSD, only base lives outside of /usr/local. If you installed any softwares either through Ports, pkg, or plain old "download and build in my home folder", all of it is installed to /usr/local. Keeps softwares isolated from base.
Fri Aug 04 2023 22:00:26 EDT from nonservatorNot to derail but I had a lot of fun with ATA over Ethernet - what sort of similar offerings are current?
i know its been tried, but we need an iCPU protocol too, now that network speeds are decent enough to do it i think.
Ok, so as I expected, /usr/local is more traditional, and is still used in FreeBSD. I'll stick with it :)
ATA over Ethernet is pretty cool, but it never really caught on in data centers.
I find this disappointing because it made sense to replace Fibre Channel with Ethernet. And that's happening ... but it's happening with iSCSI and now NVMEoF.
Here's the thing, though: as a Fibre Channel replacement, no one really routes their storage traffic. Initiators and targets are almost always on the same network. And it's all done with switched networks that don't really drop frames. But with iSCSI and NVMEoF we're stuck with the overhead of TCP and IP anyway.
In my data centers I usually indicate a preference for NFS, because you can have multiple initiators without having to use a parallel-access filesystem.