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
There are times when you don't want to put a nonstandard development library in /usr/local/{lib,include} becuase it would then be part of the default compiler paths. That's when I like to use /opt/foo instead of /usr/local/foo
Hang on let me get some popcorn before Kitty eats you alive.
:)
Fri Aug 11 2023 11:18:58 AM EDT from LoanShark2023-08-02 15:37 from LadySerenaKitty
Since FreeBSD 6.x, teh default place for home folders is /usr/home,
and /home has been a symlink to /usr/home.
What's BSD?
Berkeley Software Distribution. Sometimes called Berkeley Unix. Currently there are 3 main BSD projects - FreeBSD, OpenBSD, and NetBSD. Others, like DragonflyBSD, GhostBSD, TrueNAS, et al, are forks or downstream projects from one of the main trio (usually FreeBSD).
Fri Aug 11 2023 11:18:58 EDT from LoanShark
What's BSD?
Just think, if Sun hadn't switched from BSD to SysV with version 5, the whole world would probably be BSD-ish today.
having done more than his share of porting software between weird
systems.
Yeah, a decade or two ago. These days I run Linux locally, to roughly match prod, and try to tell the macOS users at the office to fuck off and deal with their local environment themselves. I am not their tech support.
Preview of 14 is out.
And while i dont pretend to be the expert our resident cat is, that is what im reading.
Sat Aug 26 2023 11:18:41 AM EDT from IGnatius T FoobarWait what? 14 isn't even out yet. Will 14 be the last version supporting 32-bit?
And after another drive freak out on my desktop this morning, shoved in a 250g, loaded it up. Booting fine. Moved my home folder off the previous drive ( its fine.. its the machines, but if im doing this, i wanted ti make it JUST data. ) to an external SSD, via USB3. This was after 2 hours of copy across USB .. again.. but at least no more of that nonsense. and why i went this route.. im tired of doing this. Might move it to NAS later, or just keep it physical so i can take it with me.
( these things just cant do huge SSD reliably and have stuff like this stupid ass keyboard plugged in at the same time. its a power thing )
That's the plan! The usage of 32-bit machines is no longer worth the effort in maintaining support for them. The only reason it wasn't ripped out of 14.x is because people were still using 32-bit machines with the 14.0-CURRENT branch. This was discussed months ago. 15.x won't be having any 32-bit support and that can be done because the 15.x branches haven't been made yet.
Sat Aug 26 2023 11:18:41 EDT from IGnatius T FoobarWait what? 14 isn't even out yet. Will 14 be the last version supporting 32-bit?
The one consolation is i dont see 'generic' 64 bit being phased out in our lifetime.
if it does happen, its to a totally different concept. ( such as quantum chips or 100% GPU or something radical. )
I think about that often, actually. 64 bits is an awful lot of address space. Even the current crop of 64-bit AMD chips are only using 48 bits of virtual address space, with a set of rules governing how it is used so that the remaining space may be cleanly added in the future.
They actually had to make it two x 47-bit virtual address spaces because of Windows. Their stupid kernel reserves the top half for the kernel and the bottom half for userspace.
So in practice the maximum addressable virtual memory is 2^47, oor 128 TB. Maybe it's twice that on non-windows systems if they let you use the top half. As an experiment, I just put together the following little program:
#include <stdlib.h> #include <unistd.h> #include <string.h> #include <stdio.h> void stacko(int baz) { char *sta = "static string"; char *dyn = malloc(10); strcpy(dyn, "bar"); printf(" Static: %p\n", sta); printf("Dynamic: %p\n", dyn); printf(" Stack: %p\n", &baz); } int main(int *argc, char **argv) { stacko(12345); exit(0); }
The objective was to see what kind of address ranges the system would use for static values, memory allocated on the heap, and items passed up the stack. Here is the output:
Static: 0x55a55898e004 Dynamic: 0x55a559d9b2a0 Stack: 0x7ffddcbcf56c
As you can see, the static and heap memory was somewhere in the middle, the stack was way up top, but both were in the 00000000'00000000 to 00007FFF'FFFFFFFF range, suggesting a 47-bit address space, at least from the point of view of what is visible by a single process. This example ran on a Linux operating system, which uses the Linux kernel, running on genuine AMD64 hardware (not an Intel clone).
Going to the hardware store today, pulled out my little tape measure to take with me. Tho its mostly worn off since its been my 'go-to' measure, it used to say "FreeBSD foundation" on the back. Sort of forgot that since its been so long. Small round semi-transparent purple thing.
i forget which conference i got it from, and since hardly anyone has conferences anymore.. doubt ill ever see another.
Not that im a fan of crowds, or flying ( DHS.. such a hassle ). but when they were close enough to drive to it was a nice change in scenery for a few days, on the company dime. I used to be the "traveling IT guy".. drove about 2k miles a week in the old days, sometimes overnight stay if things ran late, but that was different than going and parking yourself somewhere for a few days for 'work related' but not actually 'work'.
(Skeptics take note: I'm running btrfs and I lost no data.)
I'm not the kind of person who constantly rebuilds machines, so I build for long term steady state. And for this round, I decided to ditch Ubuntu and go back to regular Debian. And you know what? For the most part I can't even tell the difference. I told it to install KDE, and all the settings that were stored in my home directory just picked right back up and everything looks just like it did before.
Easy, stable, and flexible. We really do have a better ecosystem than Microsoft and Apple, no matter how hard they plug their ears and shout at us.
Mon Sep 04 2023 10:41:49 PM EDT from IGnatius T FoobarI'm not the kind of person who constantly rebuilds machines, so I build for long term steady state. And for this round, I decided to ditch Ubuntu and go back to regular Debian.
Been meaning to do this for a while now, so you just cemented the decision when it actually happens.
My issue was the walled garden they were building, off the backs of the Debian team. I could see that from day one. And extensions they pushed when base Debian was trying to avoid it ( still pissed about systemD )
Tue Sep 05 2023 09:29:39 EDT from IGnatius T FoobarFor the record, I have no objection to Ubuntu. They had a more polished end user experience for quite a long time. But now everything has sort of caught up and is in a good steady-state, and I like the idea of being more baseline.
I've always disliked System V Init and so `systemd` is an improvement.
My preference would have been to go back to System III Init. If I were asked to design something, I would have stuck with `/etc/inittab` and added an `/etc/inittab.d` directory, like everything else has. Then you could start up single-line background commands, do `/etc/rc` style startup scripts, just about everything.
But `sysvinit` and its `/etc/rc.?/*` hierarchy are botched-abortion-level ugly. May they rust in pieces.
Not saying the old init system was perfect. But I had 2 main beefs with SystemD ( well 3, if you include who was doing it . i hate Lennart as much as i hate Gates, for similar technical reasons )
1 - When you have a working system that isn't 'bad' , but isn't 'perfect' you fix up what is there, dont toss it out just to pretend you are special. Paint the old house, dont rebuild it from scratch.
2 - All the extra stuff that was tacked on to it "just because we can" ( and to help with the virus like lock-in mentality ). Almost becoming its own kernel ( ok exaggerating a little. a little )