# portsnap being retired - what's the alternative?



## richardtoohey2 (Aug 4, 2020)

Hi,

portsnap being retired:



			'[HEADS UP] Planned deprecation of portsnap' - MARC
		


I use "portsnap fetch extract" on a new install, and "portsnap fetch update" to get updates - does anyone know what the alternatives are to those?

I'll go digging and might answer my own question soon.

Thanks.


----------



## msplsh (Aug 4, 2020)

I'm going to guess it will be `poudriere ports -u` based on that email, but having never used poudriere.


----------



## Mjölnir (Aug 4, 2020)

you can also use svnlite(1)


----------



## richardtoohey2 (Aug 4, 2020)

Thank you.

Looks like:

"portsnap fetch extract" might be "poudriere ports -c"
"portsnap update" might be "poudriere ports -u"

But then all the fun & games of setting up poudriere (I know it's not a huge fuss but it's more than a couple of in-base commands).

So I'll see if I can figure out the svnlite commands to get the same as the portsnap commands.


----------



## Phishfry (Aug 4, 2020)

Does seem mighty shortsighted to depreciate `portsnap`.
Lets face it `svnlite` alone does nothing. You have to figure out where to point it and where the files land.


----------



## sidetone (Aug 4, 2020)

I like net/svnup, as I can configure where it updates from through svnup.conf in local/etc/.


----------



## richardtoohey2 (Aug 4, 2020)

There's some svnlite info here from a few years ago, so I'll start there: https://forums.freebsd.org/threads/syncing-up-the-ports-tree-on-a-fresh-install.55998/


----------



## a6h (Aug 4, 2020)

mjollnir said:


> you can also use svnlite(1)


 devel/subversion is my favourite. There's a problem for users with low bandwidth: ~ 1.7 GB vs. 50 MB portsnap


----------



## Phishfry (Aug 4, 2020)

My problem with this move is that `portsnap` is a tool that does one thing and does it well.
`svnlite` is a general downloader and file syncronizer.

Instead of removing `portsnap` maybe they should add the ability to download quarterly with an option flag like -q for quarterly and -h for head.


----------



## a6h (Aug 4, 2020)

richardtoohey2 You need only three commands
First time: `svn checkout https://svn.freebsd.org/ports/head /usr/ports`
Update: `svn update /usr/ports`
Fixing lock problem: `svn cleanup /usr/ports`


----------



## drhowarddrfine (Aug 4, 2020)

I finally started using subversion because FreeBSD did. Now they're switching to git which I used to use. Now they're saying svnlite is an option but...but...


----------



## richardtoohey2 (Aug 4, 2020)

Phishfry - yes, I'm happy with portsnap (and portmaster).  But I don't do anything to maintain them, so if the people who actually do the work say they aren't going to any more, then I'll have to change.

vigole - thanks - but isn't svn from the port/package - so it's not in base?  A bit chicken-and-egg.  Will similar commands work with svnlite?

That other thread also suggests I'll also need a make index (I do use the INDEX-xx files sometimes).

drhowarddrfine - yes, I'm also confused about svn/git.  Think it's all part of the move-everything-to-poudriere pattern.


----------



## a6h (Aug 4, 2020)

drhowarddrfine said:


> Now they're switching to git


Does that mean no more _svn_ and we have to use _git_ commands?


----------



## a6h (Aug 4, 2020)

richardtoohey2 said:


> @vigole - thanks - but isn't svn from the port/package - so it's not in base? A bit chicken-and-egg. Will similar commands work with svnlite?


svnlite is completely fine.
[EDIT] and it's recommended by The Handbook.


----------



## drhowarddrfine (Aug 4, 2020)

vigole Yes. They're moving everything off svn to git. I fear it is based on popularity and no technical reason but I haven't bothered to read the reasons why. 

For myself, as a sole developer, I find git more than I need and clunky. It's easy to get yourself into trouble. Subversion, which I never used before now, is a piece of cake.


----------



## a6h (Aug 5, 2020)

drhowarddrfine said:


> It's easy to get yourself into trouble


Anything beyond _git clone _ is always getting me into trouble. I have to keep an eye on git cheat sheet. Evidently, there's something wrong with git syntax/grammar, I can't put my finger on it, but there's something!


----------



## sean137 (Aug 5, 2020)

drhowarddrfine said:


> For myself, as a sole developer, I find git more than I need and clunky. It's easy to get yourself into trouble. Subversion, which I never used before now, is a piece of cake.



Agreed. But, FreeBSD is not a solo-developer project, it is the exact opposite, and for massively distributed projects, git is really useful (though its UI/syntax is subpar).


----------



## cmicallef (Aug 5, 2020)

So if I'm open to giving the git repo of ports a go, will these do the job?

First time `sudo git clone --depth 1 https://cgit-beta.freebsd.org/ports.git`
Updates `sudo git pull --all`


----------



## trev (Aug 5, 2020)

vigole said:


> Anything beyond _git clone _ is always getting me into trouble. I have to keep an eye on git cheat sheet. Evidently, there's something wrong with git syntax/grammar, I can't put my finger on it, but there's something!



That's my experience too. I've never had a problem with rcs or svn(lite).


----------



## memreflect (Aug 5, 2020)

With svnlite, you can also use a quarterly branch instead of the latest/head snapshot that portsnap limits you to, in which case, you would also want to know how to switch branches to be able to change your ports tree to a newer or older branch:

```
# Switch to the 2020Q2 branch (the one before the current 2020Q3 branch)
svnlite switch ^/branches/2020Q2 /usr/ports
# Switch to head
svnlite switch ^/head /usr/ports
```

New portsnap(8) switches like `-q` for quarterly and `-h` for head would accomplish the same thing, but then you have arguments about whether portsnap should default to the new `-q` behavior or retain compatibility with `-h` being implied.

I still would prefer svnlite, however, because it means I don't need to download a large snapshot tarball every time: a set of diffs is a lot smaller than a full tree.  Just don't delete the .svn/ directory at the top of the tree, else it's no better than portsnap.

That said, svn/svnlite does have at least one downside beyond knowing what URL to use for initial checkout: running find(1) or `grep -r` in the toplevel /usr/ports directory will result in searching the /usr/ports/.svn directory as well, so you need to find a way to exclude that directory; how you accomplish that can depend on the context of your search. Of course this applies to git as well.

As for the svn/git argument, git is definitely faster.  GhostBSD actually disabled the svn prompt by default in its shells/fish port because it was so slow in large repos that even `cd dirname` took several seconds to wait for the svn command to complete before printing the shell prompt.

Of course, git is also more complicated to use since most git commands other than git-clone(1) and git-init(1) require you to already be inside the checked-out source tree.  As an example, a simple and intuitive one-liner like `svnlite update /usr/ports` becomes the more complex `sh -c 'cd /usr/ports && git pull'` or even a shell function (sh(1)) for the sake of something easy to type and remember:

```
update-ports() {
  if cd /usr/ports; then
    git pull
    cd - >/dev/null    # Not sure if this line is necessary, but why take chances?
  fi
}
```

Every tool has its trade-offs.  At the very least, git can be faster while offering the same incremental update advantage as svn/svnlite, something that portsnap in its current incarnation just cannot do.  Naturally you won't even need to worry about such a thing if you use poudriere-ports(8) instead of manually updating the repo, but I understand that not everybody wants to use Poudriere.


----------



## drhowarddrfine (Aug 5, 2020)

sean137 said:


> for massively distributed projects, git is really useful


So is subversion. And has been used that way by FreeBSD for a long time--and still today.


----------



## richardtoohey2 (Aug 5, 2020)

"portsnap fetch extract" alternative with svnlite has gone to plan so far:


```
:/usr # mv ports old-ports
:/usr # mkdir ports
:/usr # svnlite checkout https://svn.freebsd.org/ports/head /usr/ports
A    ports/multimedia
A    ports/multimedia/libva-intel-media-driver
A    ports/multimedia/libva-intel-media-driver/files
A    ports/multimedia/py-subliminal
...
A    ports/Keywords/fontsdir.ucl
A    ports/Keywords/shared-mime-info.ucl
A    ports/Makefile
A    ports/.gitmessage
 U   ports
Checked out revision 544188.
:/usr # cd /usr/ports/
:/usr/ports # make index
Generating INDEX-12 - please wait..--- describe.accessibility ---
--- describe.arabic ---
--- describe.archivers ---
...
```

Slower than portsnap fetch extract but I assume that's because it (svnlite) is carrying out file-by-file network operations rather than downloading a compressed archive and then working locally.  Just an observation (or maybe stating the obvious!) not a whinge.  The initial check-out is something I'd only do once on a machine anyway.

I'll wait a few hours and then try the "portsnap fetch update" alternative (svnlite update /usr/ports) to see what's new.


----------



## Mjölnir (Aug 5, 2020)

vigole said:


> richardtoohey2 You need only three commands
> First time: `svn checkout https://svn.freebsd.org/ports/head /usr/ports`
> Update: `svn update /usr/ports`
> Fixing lock problem: `svn cleanup /usr/ports`



Anyone is free to make such command an alias for `portsnap` or write a wrapper script.  Enhancements like the mentioned switching between branches will very fast appear & shared in _Usefull Scripts_ here in the forum.
IIRC, svnlite(1) is svn(1) without Python scripting support?
Yes, _svn/svnlite_ is buggy regarding bandwidth: it downloads twice as much data volume as would be necessary, uncompressed (the metadata holds an exact copy of each file)...  If anyone has an idea how to download only the missing .svn metadata, please drop me a note.  I'm dialing in via WWAN, my contract in limited on volume.


----------



## olli@ (Aug 5, 2020)

Note that there is also net/svnup. It’s a very small, lightweight tool for downloading and synchronizing trees from a Subversion server. I use it regularly to get /usr/src (-stable) on machines, but it can also be used for /usr/ports. With the default configuration, it’s as easy as typing `svnup ports`.


----------



## diizzy (Aug 5, 2020)

Since we're moving towards git (soonish) I somewhat doubt svn is going to be a viable solution/workaround in the long run...


----------



## T-Daemon (Aug 5, 2020)

If you like it or not, it would be more effective beginning to use git rather than subversion control tools in the long run. Sooner or later FreeBSD will be migrated to git. For portsnap users why using subversion control tools now? In the mail no deadline for portsnap(8) is given. Maybe it can be used until then. If not, using git would be the logical choice instead of svn(lite)/svnup.

From the April, 2020 - June, 2020 FreeBSD Status report, Git Migration Working Group:

"_We expect to be ready for the migration in the next quarter._"


----------



## diizzy (Aug 5, 2020)

The issue is bootstrapping, there's no working variant of a git client that's suitable (non gpl licensed) to be included into base.
https://github.com/khanzf/opengit is about as close as you get afaik


----------



## unitrunker (Aug 5, 2020)

There are problems on both sides ... of the svn vs. git decision.

As memreflect said, the flaw in portsnap is it can only fetch HEAD. It can't do quarterly. I'd prefer a single tool that covered both. This could be fixed in portsnap. Worst case is it falls back to using libsvn to do a 'svn checkout' of quarterly.

git may be desired by ports maintainers and kernel coders - but it doesn't offer any benefit for read-only 'buildworld' users. The normal use case for users (those without a FreeBSD commit bit) is to get the latest (or latest quarterly branch) and build. You don't care about commit history or any other branches. 'git clone' pulls down the entire repository. This is very useful for some - but not so when all you want is a build of the current code. To avoid getting gigabytes of commit history you can use:


```
$ git clone -depth 1 -branch <branch-name> https://url.freebsd.org/some/path
```

This would still use more disk space than 'svn checkout' but may be good-enough.

A compromise path forward is to keep the svn tools in base. The server hosting the git repository can deploy tools to make a git repository look like a subversion repository (github does this today) - allowing svn and svnlite to continue to function. Folks with a FreeBSD commit bit would use the git interface to do branching, PRs, and merging.

For folks wanting to avoid GPL bits in base, A few OpenBSD contributors are working on a git inspired tool called 'got'. It could be made git compatible - like svnlite but for git. That would require some work.

If we do end up with 'git clone' as the way forward, here is one consolation prize. You can use your local clone to track your local changes (custom kernel or port build options). Just do a git pull whenever you want your local repository updated. This will on occasion require some manual edits for merge conflicts - but that is normal for both git and svn.

Edit: '-depth 1' implies '-single-branch' but you still need a branch name.


----------



## olli@ (Aug 5, 2020)

diizzy said:


> Since we're moving towards git (soonish) I somewhat doubt svn is going to be a viable solution/workaround in the long run...


As far as I know, there are plans to keep SVN servers running in read-only mode for an indefinite time after the switch to git, so net/svnup should continue to work. And apart from that, it’s also not unlikely that someone will come up with a similar BSD-licensed tool for git (let’s call it “gitup”).


----------



## unitrunker (Aug 5, 2020)

Here is got.

I ported an earlier release to FreeBSD as a toy exercise.









						C - Game of Trees (got)
					

https://gameoftrees.org/  I like the idea a BSD friendly git work-alike. Like most OpenBSD projects - this one is ISC licensed. The code is very much entrenched into OpenBSD's own eco-system.   1. pledge, unveil, recallocarray. 2. imsg (which thankfully already exists in ports as part of...




					forums.freebsd.org


----------



## kpedersen (Aug 5, 2020)

Subversion in base is really handy. I don't think this is possible with Git.

Also, if you look at win32 ports, svn is tiny and portable. Just a few executables. Whereas Git is impossible to port and requires an entire Cygwin / Msys2 POSIX compatibility layer. Typical Linux shite frankly.

However, if the GitHub workflow is what the developers pine for then atleast GitHub (for now) provides support for Subversion.

i.e the following works:

`svn co "https://github.com/osen/emscripten-devel.git/trunk" emscripten`

And once Microsoft drops subversion support, hopefully the OpenBSD guys will have completed their GoT (http://gameoftrees.org/) client that perhaps we can include in base.

Edit: That it looks like unitrunker has already made great progress with


----------



## drhowarddrfine (Aug 5, 2020)

Another thing that bothers me about git is that Linus created that over one weekend and ran with it. Sure, it has had improvements and additions over the years but I would have an uneasy feeling about someone building the foundation of my house so fast over the weekend.


----------



## rigoletto@ (Aug 5, 2020)

Subversion is a lot of saner than Git, but can be extremely slow and make it a LOT OF harder to do things like branching.


----------



## trev (Aug 5, 2020)

I don't wish to rain on anyone's parade, but the ports mailing list says Subversion is going away too in FreeBSD's migration to git.


----------



## drhowarddrfine (Aug 5, 2020)

gpb From your same source I presume:


> took the challenge into his own hands and *disappeared over the weekend to emerge the following week with Git*. took the challenge into his own hands and disappeared over the weekend to emerge the following week with Git.


That's not the same source I read. I read about it on the mailing list when he first introduced git way back when. He said something along the lines of, "I knew I could do it over the weekend and I did!"


----------



## kpedersen (Aug 5, 2020)

trev said:


> I don't wish to rain on anyone's parade, but the ports mailing list says Subversion is going away too in FreeBSD's migration to git.



I do find it fairly amusing that the following:

`pkg install git`

Happens to drag in subversion. Something in the FreeBSD Git port requires not just `svnlite` but the full fat `svn`.

So either they fix that, or we won't be saying goodbye to Subversion just yet!


----------



## unitrunker (Aug 5, 2020)

I believe you can use git to work on a local repo and push commits to a subversion server. Git needs the SVN libs to do this.

All I ask is that 'git help' should not open a browser.


----------



## shkhln (Aug 5, 2020)

unitrunker said:


> All I ask is that 'git help' should not open a browser.



It doesn't. Man page suggests that might happen if you messed with the _help.format_ configuration setting.


----------



## sidetone (Aug 5, 2020)

GIT uses a GPL2 license. I don't see how that's going into the FreeBSD base.

svnup can't do everything that svn or svnlite can do. I could only get ports and system updates from it. Perhaps the `[defaults]` section of the default freebsd.org host would have to be overriden in a subsection to use this with another host.

In /usr/local/etc/svnup.conf: each section is referenced, of which branch and target to use, so it doesn't have to be typed out each time as in svn or svnlite. The protocol can also be set from http to svn.


```
[defaults]
work_directory=/var/tmp/svnup
host=svn0.us-east.freebsd.org
protocol=svn
verbosity=2
trim_tree=0
extra_files=0

[release]
branch=base/releng/12.1
target=/usr/src

[ports]
branch=ports/head
target=/usr/ports

# To update only a specific directory
[net]
branch=ports/head/net
target=/usr/ports/net
```

What's in the parenthesis (except defaults) is used with `svnup` for that.

Using svnup with its configuration file is simpler than...

```
svn checkout https://svn.freebsd.org/ports/head /usr/ports
svn update /usr/ports
svn cleanup /usr/ports
```


----------



## Phishfry (Aug 5, 2020)

Somewhat off topic but in the same vein.
I did not realize that devel/git-lite was a FreeBSD only construct.
Recently I attempted to port a Linux software to FreeBSD and started by downloading the source from github to a Linux VM.
`apt-get install git-lite` did not work so I went looking for it and discovered it was only used on FreeBSD.
I used subversion instead to fetch the source.


----------



## Criosphinx (Aug 5, 2020)

I don't get it . The change to git only affects developers and people who want to contribute, I can't find the page but I read that one of the reasons was that it is very difficult to accept patches and merge patches with svn. It has nothing to do with end users.

Besides the topic title is about portsnap alternatives and it seems that it can be substituted by svnlite included in base or poudriere which is well documented.


----------



## richardtoohey2 (Aug 6, 2020)

Criosphinx - if that's the case that sounds good.

I don't mind picking up something new if I have to but don't want to jump from portsnap to svnlite and then have to move again to a git-based flow - for keeping-up-to-date with ports.  So if moving to svnlite is going to work then I'll carry on.

I've waited overnight and there are some updates, so I've done svnlite update /usr/ports.


```
svnlite update /usr/ports
pkg version -vIL=
```
... nothing ...

I know from a machine that I'm using portsnap up that there's a new version of apache24:


```
portsnap fetch update
pkg version -vIL=
...
apache24-2.4.43                    <   needs updating (index has 2.4.46)
```

If I go back to my svnlite machine, this seems to do the same thing:


```
cd /usr/ports/
make index
...
pkg version -vIL=
apache24-2.4.43                    <   needs updating (index has 2.4.46)
```

Rummage through FMs and for -I (i for igloo):


```
If not specified then the ports index file will be used if it exists (-I).
```


----------



## richardtoohey2 (Aug 6, 2020)

vigole said:


> Fixing lock problem:  svn cleanup /usr/ports


I've not done this step - what is it needed for?  Don't mean that rudely, I would like to understand what the problem is that I haven't hit ... yet!


----------



## a6h (Aug 6, 2020)

You don't need it, unless there's a problem and svn complain that it's locked! Sometime for different reason (e.g. connection drop, ...) the process gets interrupted. SVN will complain, locked and you have run this command, and after that resume the process as usual.


----------



## rigoletto@ (Aug 6, 2020)

Phishfry said:


> Somewhat off topic but in the same vein.
> I did not realize that devel/git-lite was a FreeBSD only construct.
> Recently I attempted to port a Linux software to FreeBSD and started by downloading the source from github to a Linux VM.
> `apt-get install git-lite` did not work so I went looking for it and discovered it was only used on FreeBSD.
> I used subversion instead to fetch the source.



This is the same thing but built with the minimal necessary amount of compile time OPTIONS ON.


----------



## olli@ (Aug 6, 2020)

Criosphinx said:


> I don't get it . The change to git only affects developers and people who want to contribute, I can't find the page but I read that one of the reasons was that it is very difficult to accept patches and merge patches with svn. It has nothing to do with end users.
> 
> Besides the topic title is about portsnap alternatives and it seems that it can be substituted by svnlite included in base or poudriere which is well documented.


Of course, the change to git _will_ affect normal users who use Subversion-based tools like `svn`, `svnlite` or `svnup`, as soon as the old Subversion servers have been switched off.

So, changing from portsnap to, say, svnlite now does _not_ appear to be a particularly good idea …


----------



## olli@ (Aug 6, 2020)

By the way, another option is to simply download https://download.freebsd.org/ftp/ports/ports/ports.tar.gz (available via FTP, HTTP and HTTPS). This is one 60 MB blob, but if you do that just once per week or so, it shouldn’t be much of a problem, unless you’re seriously bandwidth-limited. If you have several machines, you can download it to one of them, and then rsync(1) or cpdup(1) it to the others.

The advantage of that approach is that it works independent from any CVS / SVN / Git / whatever, it will continue to work indefinitely, and it’s dead simple. (Only works for head, though. I’m not aware of quarterly snapshots available for download like that.)


----------



## richardtoohey2 (Aug 6, 2020)

olli@ said:


> So, changing from portsnap to, say, svnlite now does _not_ appear to be a particularly good idea …


_Full reverse thrust Mr Sulu!
The engines canna take any mair, captain!_

Think the download of ports.tar.gz sounds like a good option to investigate, so will look at that next.  One day I'll end up with poudriere I'm sure, but it always seems like a bit more work (and Larry Wall said programmers are lazy so I have an excuse!)


----------



## T-Daemon (Aug 6, 2020)

olli@ said:


> By the way, another option is to simply download https://download.freebsd.org/ftp/ports/ports/ports.tar.gz (available via FTP, HTTP and HTTPS).
> ...
> (Only works for head, though. I’m not aware of quarterly snapshots available for download like that.)



You can get a zip compressed file for quarterly ports from https://github.com/freebsd/freebsd-ports/tree/branches/2020Q3 (look for the "_Code_" marked green button).

This is also valid for ports head, base system head, release, releng, stable. I used to download for a while this way ports and base source.

Maybe someone in this thread has mentioned it already, GitHub supports subversion clients, so one is not necessarily bound to git. I haven't downloaded from the FreeBSD GitHub web page for a while, I've forgotten that option:









						Support for Subversion clients - GitHub Docs
					

GitHub repositories can be accessed from both Git and Subversion (SVN) clients. This article covers using a Subversion client on GitHub and some common problems that you might run into.




					docs.github.com


----------



## olli@ (Aug 6, 2020)

T-Daemon said:


> You can get a zip compressed file for quarterly ports from https://github.com/freebsd/freebsd-ports/tree/branches/2020Q3 (look for the "_Code_" marked green button).
> 
> This is also valid for ports head, base system head, release, releng, stable. I used to download for a while this way ports and base source.
> 
> ...


Interesting. I wasn’t aware that Github had copies of the FreeBSD ports collection and the source trees. Is this an “official” service of the FreeBSD project that will be available indefinitely? And are these synchronized with the project’s SVN server instantly, or do they lag behind by a certain amount of time?

Regarding Github’s support for subversion clients: If that could be made to work with net/svnup somehow, that would be very cool.


----------



## T-Daemon (Aug 6, 2020)

olli@ said:


> Is this an “official” service of the FreeBSD project that will be available indefinitely?



All repositories are officially FreeBSD. Main page:








						The FreeBSD Project
					

The FreeBSD Project has 53 repositories available. Follow their code on GitHub.




					github.com
				




People involved:








						The FreeBSD Project
					

The FreeBSD Project has 53 repositories available. Follow their code on GitHub.




					github.com
				






olli@ said:


> And are these synchronized with the project’s SVN server instantly, or do they lag behind by a certain amount of time?



I followed and compared the ports directory revision from https://svnweb.freebsd.org/ports/head and latest commit  on  https://github.com/freebsd/freebsd-ports for a while. There is a delay.


----------



## drhowarddrfine (Aug 6, 2020)

T-Daemon said:


> All repositories are officially FreeBSD.


It really bothers me that the kingdom is now in the hands of a third, for-profit party.


----------



## olli@ (Aug 6, 2020)

drhowarddrfine said:


> It really bothers me that the kingdom is now in the hands of a third, for-profit party.


No, they’re just read-only copies. The “authoritative” repository is still the FreeBSD project’s own Subversion server.

And even when FreeBSD switches from svn to git, that does not mean that the primary repository will be hosted on GitHub.


----------



## kpedersen (Aug 6, 2020)

olli@ said:


> that does not mean that the primary repository will be hosted on GitHub.



Really? That is a relief. Normally when people say they want to use Git, they really just mean that they want the trendy fun experience of Microsoft GitHub. XD

Especially since hosting your own Git server isn't exactly elegant these days (either massive VMs, shedload of python PIP deps, just bare minimum with ssh or of course the inbuilt git server with no authentication).


----------



## T-Daemon (Aug 6, 2020)

The following is from the April-June 2020 Status Report, Project Git Migration Working Group:

Beta doc git repo    URL: https://cgit-beta.FreeBSD.org/doc
Beta ports git repo    URL: https://cgit-beta.FreeBSD.org/ports
Beta src git repo    URL: https://cgit-beta.FreeBSD.org/src

Looking at the URL's it suggests the primary git repositories will be on own servers, unless the plan is to move the repositories after the ending of the beta phase somewhere else.


----------



## a6h (Aug 6, 2020)

drhowarddrfine said:


> It really bothers me that the kingdom is now in the hands of a third, for-profit party.





Spoiler: Just joking, please don't feed my reply!



Once upon a time, FreeBSD was a constitutional republic. Now it's a union, running by unelected bureaucrats!



Anyway, there's nothing we can do. Read a few emails from June 2014 to October 2014 (you can go further!) in the https://lists.freebsd.org/pipermail/freebsd-git/. Choice of words are interesting, e.g.  _"Totally [...]" "FreeBSD is getting with the program" and "just a few die hard people [...]"._ --- You've just need one of these mindsets in the upper echelons of any project.
By the way, It is hard to find any comprehensive lists of some discussions on the whole git/github thing, from genesis to revelation ... . To be specific, conversation between Core Team and/or FreeBSD foundation, who started it first, yays and nays, so forth and so on. If there's any, please share those links and possible blogs or archives. It's easier to find this kind of materials on Linux topics. There's more news and more eyes on that project. Because Linux has more user-base, and it leads me to my next point:
I completely disagree with mjollnir on [*]


mjollnir said:


> To make FreeBSD more user-friendly is a key to widen it's user base, which will result in more skilled developers after some years.


But, there's a good point: widening the user base has a gigantic benefit. We're going to have more internet stalker (blogers, social neters!, youtuber, ...) and crowd will look more closely to FreeBSD to find topics and publishing more hit-pieces ... as a result gaining more view/attention and clicks/ad. It has a nice consequences for FreeBSD: more blogs and links on different topics, such as this one [**]

[*] _I won't argue on it, it's just my personal opinion, feel free to criticise me for this one, on the other thread, over there, not here!_
[**] _Over there, Linus Torvalds picking on some dummy on mailing list, leads to world wide news headlines and detailed articles. Over here, git happens with feel of mystery and we have to read between the lines, speculate, guess ,..._


----------



## kpedersen (Aug 6, 2020)

vigole said:


> But, there's a good point: widening the user base has a gigantic benefit.



Yes and that is why I wouldn't be completely up in arms even if they did move to MS GitHub. It does make it more accessible.

However, I think Theo hit the nail on the head when he stated in an interview (I think it was this one: https://undeadly.org/cgi?action=article;sid=20191231214356) that he didn't like "users". He prefers developers because they have more initiative to fix things if anything goes wrong. They are also more likely to know what is a good direction for a project (they understand limitations). They don't suck and drain a project.

So, does FreeBSD really want more users? I personally think the answer to that is a resounding yes! but only "good" ones XD
Trying to attract a load of Android/iOS tablet users for example will do more harm than good because they will never be happy. Whereas trying to attract a load of Sysadmin users because they happen to be more up-to-scratch with the Git workflow is ideal.


----------



## a6h (Aug 6, 2020)

Thanks kpedersen excellent, you are speaking my mind.


----------



## msplsh (Aug 6, 2020)

The move to git is to attract more developers.  Users who want a portsnap alternative should be using poudriere.

People who still want to complain about switching to git have missed the boat and are wasting everybody's time.


----------



## sidetone (Aug 6, 2020)

I can see why they want to get rid of portsnap itself. But SVN as a way to update source code needs to stay. The functionality of `svnup` for this is great. I wish a configuration file like this was in the base rather than local.

They would have to have a GIT software BSD alternative before attempting to use a GIT repository method for this. GIT due to its license can't go into the base without changing what FreeBSD is intended to be.


----------



## unitrunker (Aug 6, 2020)

Alternate git tools:

libgit2 - GPLv2 with linking exception.
go-git - Apache 2 license (active).
got - ISC license (active).
git-rs - MIT license (does not look active)


----------



## drhowarddrfine (Aug 6, 2020)

msplsh said:


> The move to git is to attract more developers.


I'm pretty sure that is not a top of mind point when a developer wants to work on any software. It may be a positive for some but not a reason people would come here.


----------



## olli@ (Aug 6, 2020)

msplsh said:


> The move to git is to attract more developers.  Users who want a portsnap alternative should be using poudriere.


I use portsnap to update /usr/ports nightly with a cron job. Using poudriere for that would be overkill. I mean, poudriere just uses svn internally, so I can just use svn myself (or better yet, svnup) without needing poudriere.

Anyway, portsnap will continue to work for quite some time, so there is no reason to rush now. I would at least wait until the project has changed from svn to git. And then you can decide what’s the best way to update your ports collection in the future. Maybe at that time a new tool like “gitup” exists, or the “got” thingy of the OpenBSD folks is up to the task, or whatever. Or use svnup against the SVN-API of GitHub. There may be quite many possibilities.

Bottom line: Don’t worry. Everything will be fine.


----------



## jb_fvwm2 (Aug 6, 2020)

sidetone said:


> I can see why they want to get rid of portsnap itself. But SVN as a way to update source code needs to stay. The functionality of `svnup` for this is great. I wish a configuration file like this was in the base rather than local.
> 
> They would have to have a GIT software BSD alternative before attempting to use a GIT repository method for this. GIT due to its license can't go into the base without changing what FreeBSD is intended to be.


I wonder if both git AND svn can be used for source and ports?  That would make new installs easier for those used to svn and not git, for essential ports [ video, networking ] that have to be built at first, or even as part of the install script.


----------



## sidetone (Aug 6, 2020)

jb_fvwm2 said:


> I wonder if both git AND svn can be used for source and ports?  That would make new installs easier for those used to svn and not git, for essential ports [ video, networking ] that have to be built at first, or even as part of the install script.


I was wondering if SVN would be kept only for FreeBSD updates, and GIT for ports and documentation. I was looking into comparisons of the two. SVN was described as monolithic, and GIT as useful for smaller projects that didn't need to update the whole source tree.

For downloading FreeBSD documentation, SVN required downloading the whole tree, when only a part, or a subset was needed. It makes sense to keep SVN for FreeBSD base sourcecode. In comparison, SVN is way better than CVS or CTM. For many, at least for now, SVN would remain useful for sources needed to compile the kernel. I stopped compiling my base, as it often breaks things, that prevent consecutive build/install worlds. Recompiling World is too much work for that, when unwanted services can be blocked with PF.

I have doubts about GIT, and if OS's move onto it, they'll be reluctant to leave it for something better. The current move isn't for something better, it's a bandwagon movement.


----------



## a6h (Aug 6, 2020)

sidetone said:


> For downloading FreeBSD documentation, SVN required downloading the whole tree, when only a part, or a subset was needed


As far as I know, building the documentation from source requires the whole https://svn.FreeBSD.org/doc/head.


----------



## msplsh (Aug 6, 2020)

drhowarddrfine said:


> I'm pretty sure that is not a top of mind point when a developer wants to work on any software.



Maybe they DON'T wan't to "work" on the software, don't know how FreeBSD's svn works, but they DO know how to make a fix and a PR.  Enough of those and then they might want to "work" on it.


----------



## drhowarddrfine (Aug 6, 2020)

msplsh said:


> Maybe they DON'T wan't to "work" on the software, don't know how FreeBSD's svn works


Doesn't sound like they are of any value then. How can you fix things on FreeBSD when you don't want to and don't know how it works? And being able to use git will change all that? I am sure that's not true.

If someone wants to work on an operating system or some software, git is not the thing that will make them do so and lack of git won't hold them back.


----------



## msplsh (Aug 6, 2020)

You seem to be confused with "wants to work on the operating system" and "sees a bug that is obvious and easy to fix."

It's possible to write software for FreeBSD and never use svn.


----------



## a6h (Aug 6, 2020)

If the plan is to appeal to more programmers, and it's reasonable to assume they are targeting Linux and Windows developers, especially in latter case i.e. Windows developers, It's better to have a plan to port a full-feature GIT GUI front-end to FreeBSD beforehand. I'm not aware how things work on Linux teams, but in Microsoft/.NET world, most of the windows developers almost exclusively rely on Visual Studio to work with GIT and everything else. From integrating WSL with Visual Studio, to checking GIT commits. Don't be upset if you're using Visual Studio Code, but vscode is a joke on Windows developer environments and it's mainly used by web developers. Of course some install MSYS, others using WSL or GIT installer on windows. But It's a naive assertion that presume Microsoft developers who are using Visual Studio for many years, all of sudden change the lane to FreeBSD, only because it's source is available on GitHub/GIT.Also they have to learn to work with `#!/bin/sh` too!
I'm sorry to say, I don't buy it.


----------



## 20-100-2fe (Aug 6, 2020)

sidetone said:


> I have doubts about GIT



What do you mean by "doubts"? Can you be specific?



vigole said:


> If the plan is to appeal to more programmers



That's highly unlikely, a developer doesn't volunteer for a project just because it uses GIT.


----------



## a6h (Aug 6, 2020)

20-100-2fe said:


> That's highly unlikely, a developer doesn't volunteer for a project just because it uses GIT.


I failed to start my sentence, with "_Let's assume, hypothetically_"


----------



## msplsh (Aug 6, 2020)

Fine, don't buy it from me, I don't care.  It's not like "you buying it" changes anything.  I'm just providing the rationales.






						FreeBSD Core Team 10 in Review | FreeBSD Foundation
					

Celebrating 20 years of democratic management of FreeBSD, and preparing for the next 20. As Core Team 11 readies to take over management of the FreeBSD Project, we interviewed members of Core Team 10 for their observations on a productive two years. “Democracy is a slow process of stumbling to...




					freebsdfoundation.org


----------



## 20-100-2fe (Aug 6, 2020)

msplsh said:


> Fine, don't buy it from me, I don't care.  It's not like "you buying it" changes anything.  I'm just providing the rationales.
> 
> 
> 
> ...



Ouch... 


> the lack of Git was an impediment to attracting new developers to the project





> Git is seen as a better collaboration tool



What are they smoking?


----------



## 20-100-2fe (Aug 6, 2020)

What I read in this report is consistent with what I can read in many posts on this forum and on the mailing lists.
It looks like FreeBSD is heading for the same destiny as Illumos, as described in this post (the 3rd one in the thread), for more or less the same reasons.
How sad!


----------



## shkhln (Aug 6, 2020)

20-100-2fe said:


> What are they smoking?



https://stackoverflow.com/questions/3177192/subversion-rebase


----------



## Mjölnir (Aug 6, 2020)

From that post mentioned by 20-100-2fe:


> "Desktop is not our focus. Servers are." But no one is going to run a server OS they don't know about.
> People run Linux because they know it. They use it at their home and since it is good enough for servers, they started to use it there as well.


You know this is my mantra.  Spread the word!


----------



## 20-100-2fe (Aug 7, 2020)

shkhln said:


> https://stackoverflow.com/questions/3177192/subversion-rebase



Git is not a collaboration tool, it's an SCM tool.
If they consider Git as a collaboration to, it means that for them Git = github.
Github has collaborative features - e.g. ticketing, wiki.


----------



## shkhln (Aug 7, 2020)

20-100-2fe said:


> If they consider Git as a collaboration to, it means that for them Git = github.
> Github has collaborative features - e.g. ticketing, wiki.



No, that's an entirely nonsensical take on it. FreeBSD already has a bug tracker, a wiki, and a patch review system in place. They are not going anywhere. The better collaboration part refers to Git being specifically designed around workflow where vast majority of changes are submitted by people without direct commit access. Git is just _that_ much better at dealing with patches than SVN.


----------



## drhowarddrfine (Aug 7, 2020)

msplsh You seem to be confusing wants and desires. No one who doesn't care about FreeBSD is going to fix bugs on FreeBSD just because there is a bug and just because it uses git. Yes, it's possible to write for FreeBSD and never use svn. That was never a discussion point so I don't know why you brought that up.

The only point I see in using git is (if) it solves problems that are serious enough to make one switch. One of the talking points I've seen is that it makes FreeBSD visible on github but I don't think you need to use git in order to make yourself visible on github. In fact, when one wants to get a copy of software there, github itself offers the choice of downloading a zip file instead of cloning with git.


----------



## 20-100-2fe (Aug 7, 2020)

Git has real qualities that should not be overlooked. It makes it very easy to work with subcontractors, for instance. Or to create derived works from open source software while keeping the possibility make either side benefit from the other's enhancements. Or to safely and reliably manage what will be put into production until the very last moment.

From the developer's perspective, it is easy to use and self-documented. This means it is pretty usable even without a GUI.

These are all very good reasons to adopt Git, but there is no polite way of qualifying the migration to Git in the hope it will attract new developers.
It would certainly be more profitable for FreeBSD to wonder why contributors leave or step back, but for the above reason, this will not happen.


----------



## Mjölnir (Aug 7, 2020)

20-100-2fe said:


> [...] It would certainly be more profitable for FreeBSD to wonder why contributors leave or step back, but for the above reason, this will not happen.


You mean the lack of a vision for the OS?  EDIT This would be off-topic & worth it's own thread IMHO.


----------



## 20-100-2fe (Aug 7, 2020)

mjollnir said:


> You mean the lack of a vision for the OS?  EDIT This would be off-topic & worth it's own thread IMHO.



I have a few non-technical talents and discourse analysis is one of them.
I've thus immediately noticed the article referred to by msplsh is quite similar in form and content to corporate and political discourses.
This is clearly not what I expect from the core team of a large open source project.

So to answer your question, it's not just a matter of vision, it's much deeper than that and, as it cannot be changed, not worth discussing if in the hope of improving things.
However, FreeBSD is true open source software ; if someone feels like creating another branch in the BSD family tree and deems the effort worth being made, it's possible.


----------



## Mjölnir (Aug 7, 2020)

20-100-2fe said:


> [...] I've thus immediately noticed the article referred to by msplsh is quite similar in form and content to corporate and political discourses.  This is clearly not what I expect from the core team of a large open source project.


So what do you expect from a large Open Source project?


> So to answer your question, it's not just a matter of vision, it's much deeper than that [...]


Which is _specifically_?


----------



## CyberCr33p (Aug 7, 2020)

Ports index is required for "make search". Also I think is used to speedup "pkg version -vL=" but you can also use this command without ports index. Ιs it used elsewhere?


----------



## Mjölnir (Aug 7, 2020)

CyberCr33p said:


> Ports index is required for "make search". Also I think is used to speedup "pkg version -vL=" but you can also use this command without ports index. Ιs it used elsewhere?


`egrep -ril '(index|ports)' {,/usr/local}/etc/periodic/*`

```
/usr/local/etc/periodic/monthly/300.statistics
/usr/local/etc/periodic/weekly/400.status-pkg
```
and e.g. ports-mgmt/portrac and tools alike might use it.
It's also in pkg.conf(5), so some other pkg(8) tasks/commands might access it.


----------



## drhowarddrfine (Aug 7, 2020)

20-100-2fe said:


> Git has real qualities that should not be overlooked. It makes it very easy to work with subcontractors, for instance. Or to create derived works from open source software while keeping the possibility make either side benefit from the other's enhancements.


That's for when those subcontractors are using git. That doesn't mean FreeBSD needs to use it. Subversion has great qualities, too, like centralized version control versus distributed version control which git is. This is another thing that bothers me.


----------



## msplsh (Aug 7, 2020)

drhowarddrfine said:


> No one who doesn't care about FreeBSD is going to fix bugs on FreeBSD just because there is a bug and just because it uses git.



I don't know how to make a bugfix to FreeBSD but I do know how to make a PR on a git repo.



drhowarddrfine said:


> Yes, it's possible to write for FreeBSD and never use svn. That was never a discussion point so I don't know why you brought that up.



The point of bringing that up is that svn is not integral to FreeBSD.

What's the point of beating this dead horse?  They're changing over and since most of the people on here don't commit to the repo, then I'm not sure why our opinion matters.  They're changing the bus from gas to electric.  It runs the same route, why all the squabbling...


----------



## 20-100-2fe (Aug 7, 2020)

mjollnir said:


> So what do you expect from a large Open Source project?



In short: to be driven by a mindset as open as its sources.
This implies that it finds the justification of its existence outside of itself.



mjollnir said:


> Which is _specifically_?



The same as the other members of the BSD family (and as Illumos): each of them is a cocoon and touching any single thread of it, even to make it more comfy or look nicer, is considered a vital risk by its inhabitants. They just want it to stay the same until they die, full stop.

This explains the Git story. On one hand, the CT says they decided to migrate to Git to attract new developers, but on the other hand, as it is complete nonsense, everybody in the FreeBSD community understands this will not happen, so everybody feels safe, nothing is at risk of the slightest change.

The only problem with this is for outsiders: they come in, find great things here and less great ones, they'd like to contribute and they discover they've been deceived by an insincere discourse.

Being familiar with systemics, I understand the situation and feel no resentment, but I've already noticed that some people feel quite sad and bitter about it.


----------



## a6h (Aug 7, 2020)

msplsh said:


> It's not like "you buying it" changes anything. I'm just providing the rationales.


Certainly, I've stated in my previous posts on this and the other threats, that my opinions on these subjects are irrelevant. but I retain the right to keep whining.


----------



## Mjölnir (Aug 7, 2020)

We're drifting off-topic  But I like this subject.  Maybe we should move over to another section (off-topic) or IRC (which I still not have configured...)


20-100-2fe said:


> In short: to be driven by a mindset as open as its sources.
> This implies that it finds the justification of its existence outside of itself.


I can not comment on the mindset of the CT people.  I do not know them.  Do you?  FreeBSD is widely deployed to drive services for universities, governmental & NGO's agencies/offices, companies etc., companies like Netflix, WhatsApp, NetApp etc. use it _as-is_ or building blocks/foundation to build their own OS, and it has a healthy (but small) user base.  Derived projects like user-friendly firewalls & NAS have a good reputation.  I'd call that a justification of existence.  It's written out as _"to provide a BSD OS with focus on robustness, stability & performance"_.  There seems to be a demand for such, and FreeBSD delivers in a fairly good quality IMHO.


> The same as the other members of the BSD family (and as Illumos): each of them is a cocoon and touching any single thread of it, even to make it more comfy or look nicer, is considered a vital risk by its inhabitants. They just want it to stay the same until they die, full stop.


The users mentioned above keep demanding new features, and they have vital interest to get these implemented.  I can not see any stagnatation.  Maybe some progress does not happen fast enough, but there is progress.


> This explains the Git story. On one hand, the CT says they decided to migrate to Git to attract new developers, but on the other hand, as it is complete nonsense, everybody in the FreeBSD community understands this will not happen, so everybody feels safe, nothing is at risk of the slightest change.


As I understand it, the main driving force has been limitations regarding the developer's workflow, which git seem to solve better than Subversion.


> The only problem with this is for outsiders: they come in, find great things here and less great ones, they'd like to contribute and they discover they've been deceived by an insincere discourse.
> 
> Being familiar with systemics, I understand the situation and feel no resentment, but I've already noticed that some people feel quite sad and bitter about it.


I'd like to see more concrete examples on this.  You might be right, though.  Any project beyond a certain size has political issues to cope with (_political_: inter-personal issues).


----------



## tingo (Aug 7, 2020)

20-100-2fe said:


> The same as the other members of the BSD family (and as Illumos): each of them is a cocoon and touching any single thread of it, even to make it more comfy or look nicer, is considered a vital risk by its inhabitants. They just want it to stay the same until they die, full stop.


Yet FreeBSD has changed (major changes) over the years. And still people use it! Amazing!
People will complain, because people don't like change (it is said that the only change we like is the vacation, but only if we planned it ourself). However FreeBSD users (most of them anyway) are skilled, learned and smart; they are able to look past the changed things, try out a new version of FreeBSD (with major changes) learn how to use it and carry on.

Personal experiences of major changes: ports -> packages, zfs(), devfs(5) (anyone remembering how we used FreeBSD before devfs?) and probably a lot more that I have forgotten.


----------



## kpedersen (Aug 7, 2020)

tingo said:


> because people don't like change (it is said that the only change we like is the vacation, but only if we planned it ourself). However FreeBSD users (most of them anyway) are skilled, learned and smart; they are able to look past the changed things, try out a new version of FreeBSD (with major changes) learn how to use it and carry on.



The fact that the community has endured change and proven that we can adapt is good evidence that we don't simply "dislike change". The fact is that we are nervous of regressions and incorrect decisions.

Some of the FreeBSD foundation news articles strongly suggests that someone there has drank the "cloud cool-aid" in that they pine for Git services (lets face it, probably Microsoft GitHub) and migrated the IRC to consumer Discord (with a buggy bridge).

These don't affect us (until it is too late) of course but I am also not so sure that donations will be going to the correct cause. Instead they will end up just feeding proprietary companies masquerading as "the cloud".

I trust the FreeBSD developers to make the right decision. They have proven to be correct in the past. I just hope it is the developers who are still making these decisions.


----------



## drhowarddrfine (Aug 7, 2020)

msplsh said:


> They're changing the bus from gas to electric.


No, they're changing the bus to some other means of transportation and some of us are not sure why and some of us don't feel the new means are necessary or better.


msplsh said:


> I'm not sure why our opinion matters


This isn't Linux. Our opinions matter if they're based on fact.


----------



## msplsh (Aug 7, 2020)

Matter for... what?  Opinions are not an exercise of power.

(also, really, "this isn't Linux", what kind of ad hominem is that?)


----------



## kpedersen (Aug 7, 2020)

msplsh said:


> (also, really, "this isn't Linux", what kind of ad hominem is that?)



I kinda like it. For example if you trip and fall down the stairs you say "Oops, I did a Linux!"

XD


----------



## a6h (Aug 7, 2020)

kpedersen said:


> I kinda like it. For example if you trip and fall down the stairs you say "Oops, I did a Linux!"


Wrong! vista is the correct word. The usage: I've got vista. It's vista. Historical usage/reference:


> Moss: What kind of operating system does it use?
> Police: Err... it's... Vista!
> Moss: We're going to die!


----------



## drhowarddrfine (Aug 7, 2020)

msplsh said:


> Opinions are not an exercise of power.


I'm saying that the FreeBSD people listen to users and don't have a Poettering or Linus, etc. But, really, that's like saying your elected leader listens to you when one needs to realize that political leader may have tens of thousands and more constituents. The best he can do is get a finger on the pulse, not listen to each opinion individually. Then again, how many "write your congressman" anymore?

Fun fact, it does work at times. Both of my sons are home schooled. One wanted to get into law enforcement and applied for training but was rejected by the state officials because he didn't have a high school diploma. However, he graduated summa cum laude from the same state university in Criminal Justice. No amount of writing and calling seemed to sway them so I called my Congressman. I didn't actually talk to him but the lady who answered the phone put me on a conference call with the state office that rejected him with the simple reasoning that, as she put it, "doesn't a university degree trump a high school diploma?" Needless to say, that went well.


----------



## drhowarddrfine (Aug 8, 2020)

gpb You've already been asked once to leave your political commentary at the door.


----------



## mark_j (Aug 8, 2020)

20-100-2fe said:


> Ouch...
> 
> 
> 
> What are they smoking?


They've drunk the kool-aid there's no going back... 
I'm not a fan of GIT but if the core & developers voted for it then good for them.


----------



## mark_j (Aug 8, 2020)

20-100-2fe said:


> In short: to be driven by a mindset as open as its sources.
> This implies that it finds the justification of its existence outside of itself.
> 
> 
> ...


I do question their use of the term 'community'. I don't think it's inclusive of users, certainly given what was written in the foundation's web page. However, they also mention community in the context of that useless, feel-good, survey they've put out the last few years; which involves users.
I believe core & the foundation have one main goal, the advancement of their benefactor's goals. To that end smaller/individual financial contributors are contributing to that goal, not one they be more concerned about like wifi, device support, sleep/resume support and so on. In short, I'd like to see targetted donations; but that's in my idealised fantasy world...


----------



## Deleted member (Aug 8, 2020)

sidetone said:


> That's how you get banned.


I only created the account to work on ports and that was a joke itself.  I wouldn't recommend anyone work on ports, or work on this dying operating system. Everything is built for Windows, Mac, and Linux. BSD will be relegated to fanboys, just like those continuing to run Solaris via Illumos.  There isn't any future with BSD.

And I've already deleted all posts and asked for them to delete my account.


----------



## a6h (Aug 8, 2020)

gpb said:


> I wouldn't recommend anyone work on ports, or work on this dying operating system


25 years ago, they said, Heavy Metal is dead and gone.


----------



## kpedersen (Aug 8, 2020)

gpb said:


> this dying operating system.



We are all dying gpb. (However it is fairly likely that FreeBSD will outlive us all  )


----------



## kpedersen (Aug 8, 2020)

vigole said:


> Wrong! vista is the correct word. The usage: I've got vista. It's vista. Historical usage/reference:



Haha. Vista is on a different level. For example, I reserve that term for when my dog has just crapped all over my in-laws new Persian rug.


----------



## Deleted member 63539 (Aug 8, 2020)

In no way I see FreeBSD is dying. It will be more Linux like, though. Because of the migrants from Linux. The fact is it's the only real alternative OS to Linux now. It will not go anywhere soon.


----------



## kpedersen (Aug 8, 2020)

gh_origin said:


> In no way I see FreeBSD is dying. It will be more Linux like, though. Because of the migrants from Linux. The fact is it's the only real alternative OS to Linux now. It will not go anywhere soon.



In some ways the GPL -> BSD license makes this difficult (i.e LibreOffice could suck OpenOffice dry but not vice-versa). However I do agree with you. I do hope FreeBSD retains the good parts though. There are migrants from Linux for a reason!


----------



## shkhln (Aug 8, 2020)

gpb said:


> And I've already deleted all posts and asked for them to delete my account.



You are not obliged to log in if you don't like it here. However, please refrain from deleting posts. There is nothing more annoying than seeing the rest of discussion out of context. I might have to ask the forum admins to restore that shit from backup even.


----------



## drhowarddrfine (Aug 8, 2020)

gpb said:


> this dying operating system


Been hearing that since before I started using it. But big companies like Netflix and WhatsApp keep picking it up. Damn them!


gpb said:


> I've already deleted all posts and asked for them to delete my account.


Another problem solved.


----------



## 20-100-2fe (Aug 8, 2020)

kpedersen said:


> There are migrants from Linux for a reason!



Migrants is the right word for several reasons.
I would be curious to know how many do stay, though.


----------



## a6h (Aug 8, 2020)

Windows to FreeBSD: immigrants
Linux to FreeBSD: refugees
Apple to FreeBSD: illegal aliens


----------



## Mjölnir (Aug 8, 2020)

vigole said:


> Windows to FreeBSD: immigrants
> Linux to FreeBSD: refugees
> Apple to FreeBSD: illegal aliens


And faithful FreeBSD users: _dreamers_
EDIT: Just in case (most will get it, some may not): In the US, the children of illegal immigrants are commonly called _dreamers_.


----------



## a6h (Aug 8, 2020)

mjollnir said:


> And faithful FreeBSD users: _dreamers_


I've reserved that term for OpenBSD users. But that's OK.


----------



## kpedersen (Aug 8, 2020)

vigole said:


> Apple to FreeBSD: illegal aliens



This one is so true. There is definitely a "type" of macOS user who has incorrectly arrived at the conclusion that FreeBSD is the underlying OS behind macOS and that the *coolest* thing in the world would be to bolt on a load of Apple technology to recreate macOS because that is "perfection".

And the most annoying thing about them is that they truly believe that their OS is the best and that they are so smug. Do they really think that the only reason we use FreeBSD is simply because we cannot afford a Macbook? Heck, I have 3 of the gross things in storage as test machines.

Anyway, I am taking this very far off-topic. Ignore my rambling XD


----------



## Phishfry (Aug 8, 2020)

gpb said:


> I've already deleted all posts and asked for them to delete my account.


That is a shame. I don't want you to leave. This is exactly why discussing politics never ends well.
I did not want to offend you but you started spewing some very venomous rhetoric.
Believe me I wholeheartedly agree with the First Amendment and the right to free speech.
Heck I took an oath when I joined the Navy to protect and defend the constitution.
But a civilization without rules is anarchy.
You can't yell fire in a crowded theater and discussing politics here never ends well.
A passing comment is one thing but you went over the line.

Maybe you should be blaming the originating country for the Wuhan virus.


----------



## sidetone (Aug 8, 2020)

I was saying, when someone lashes out like that, that's what typically happens on any online community.


That aside.

The virus is China's fault, it either came from a Chinese lab, or it came from the Chinese exotic food market from eating bats. Diseases emerge from coincidentally with destruction of rainforests, in this case, where those bats were from.

China messed up the most in its response, but they hardly care anyway. They only care about their economic power and that their reputation doesn't harm them too much.

That being said, Trump dropped the ball by not listening to his advisors. The source of that problem isn't his fault, but he messed up on his duty. He put too much importance of having a good show of the economy when there was a pandemic that required a lock down, which for other circumstances would be fine. It's not like Obama listened to his advisors either. It's negligence. They continually have warned these two about different things, and they haven't listened. They're both jokes.


----------



## Jose (Aug 9, 2020)

mjollnir said:


> And faithful FreeBSD users: _dreamers_
> EDIT: Just in case (most will get it, some may not): In the US, the children of illegal immigrants are commonly called _dreamers_.


This is a reference to the DREAM act that died in congress. Obama later created a similar protection for the undocumented minor children of undocumented immigrants who were brought to the US as small children. He accomplished this using an executive order called "Deferred Action for Childhood Arrivals" or DACA. The constitutionality of this order is hotly debated.

Any child of an immigrant born on US soil is called a "citizen", regardless of the immigration status of the parents. For now, anyway.


----------



## Crivens (Aug 9, 2020)

Ok folks, before any brawling occurs - it is now 0700 local time. In 3-4 hours, this here goes the way of the dodo. Shake hands, take a cold one and carry on.

We won't save the world today, at least not here.


----------



## a6h (Aug 9, 2020)

Crivens said:


> Shake hands, take a cold one and carry on.


`SYN`
`SYN-ACK`
`ACK`


----------

