FreeBSD development seems lost

[T-Aoki]

You're just lucky here... I still see plenty of times when a website works in one web browser, but not another, even in a Windows environment. I still have to tell people to 'just try a different browser, see if that works', and to ditch MS IE...

For FreeBSD-related servers having anubis installed accepts my firefox even if I'm mimic'ing it as Chrome on Windows with user agent switcher, but Gnome sites doesn't. Stop mimic'ing allowed me to access Gnome sites.

On the other hand, if I recall correctly, some sites hesitated to access with plain firefox, but mimic'ing Chrome on Windows allowed firefox to access.

 

[sidetone]

For every 'desktop user' is an web browser unavoidable, and unfortunately chrome is unavoidable:
there are web-sites that can only be read with chrome correctly, unfortunately the one of my bank.

Use your phone for banking. Make sure that there's no lingering processes or accounts on your phone.

Though, I've needed Chrome for another purpose. Chrome requires Linux compat. Don't recall if I tried if www/chromium would work for purposes, but I believe it didn't.

If I had to, I'd use a small Live Linux CD, or get a Raspberry Pi Zero, to see if AOSP works with Google apps.

 

[T-Aoki]

I have a Beelink SER5 with 32 G of RAM and 16 (threaded CPU). (Of the 32G, I think 4 is used for the GPU by default and I've left it at default). Anyway, ungoogled chromium took me around 12 hours plus or minus to build. The Beelink isn't the most powerful machine in the world, but it's decent. I usually use packages, at the time, I think ungoogled chromium was only available (using latest) as a port.

Mine is ThinkPad P52 with 32GB of RAM, 6C12T Core i7-8750H, 2.20GHz which is Coffee Lake generation.

 

[hruodr]

And until September, pkgs installed via official pkg repo (FreeBSD repo 14.x and before) for 14.3 was built on 14.2. So if the dependencies you've upgraded are accepted as dependencies for chromium pkg you have, it would be installed sanely. Not 100% sure, though.

It remained after update and worked. As said, I deleted it and could not install it anymore.

The question was: how to install a package for 14.2 in 14.3 ?

I suspect, I have to temporary change /usr/local/etc/pkg/repos/FreeBSD.conf , but I fear to spoil more packages doing that.

 

[T-Aoki]

It remained after update and worked. As said, I deleted it and could not install it anymore.

The question was: how to install a package for 14.2 in 14.3 ?

I suspect, I have to temporary change /usr/local/etc/pkg/repos/FreeBSD.conf , but I fear to spoil more packages doing that.

Look into /var/cache/pkg.
This directory is used to cache fetched *.pkg to install.

pkg does not have functionality to install *.pkg on remote repo directly, so need download to somewhere on locally mounted filesystem.

If the pkg still remains there, you can try isntalling it.

 

[hruodr]

Look into /var/cache/pkg.
This directory is used to cache fetched *.pkg to install.

25G in the directory, many versions of chromium.

If the pkg still remains there, you can try isntalling it.

How? Just filename instead of name?

EDIT: Answer found in Handbook. Man page is not clear.

 

[gotnull]

How? Just filename instead of name?

The full path is needed, for example:

pkg install /var/cache/pkg/package_name-x.x.x.pkg

Found in this thread

 

[Zare]

Also. As new hardware is released (especially with better/enhanced architecture or firmware - and.. often cheaper); there's less incentive to support existing old hardware. That's technology for you.

Actually the state of technology has never been better when it comes to innate backward compatibility ... we have been using a same architecture standard and instruction set for 20 years which is completely unimaginable for the olden days.

E.g. I bought a computer 17 years ago. I still have the inners - mainboard, CPU, ram, mobo has integrated gfx, and my first SSD is also lying around somewhere. There is absolutely nothing preventing me from installing FreeBSD 14 per handbook and expecting the complete computer and all its embedded peripherals will work.

So I'm afraid to ask what kind of computer are we talking about, that is getting knocked out of support by obsoleting pieces of kernel in between modern FreeBSD versions. Especially being around retro communities and knowing real people that "daily drive" Windows XP Pentium IIIs.

 

[astyle]

The full path is needed, for example:

pkg install /var/cache/pkg/package_name-x.x.x.pkg

Found in this thread

Ummm... it's pkg add, not pkg install... The former takes local filenames. The install flag tells pkg to look in a remote repo. And yes, there's a difference - manpages for pkg do go into more detail if you're interested.

 

[hruodr]

Ummm... it's pkg add, not pkg install... The former takes local filenames. The install flag tells pkg to look in a remote repo. And yes, there's a difference - manpages for pkg do go into more detail if you're interested.

Look at "4.4.6. Installing and Fetching Packages" here:

Chapter 4. Installing Applications: Packages and Ports

FreeBSD provides two complementary technologies for installing third-party software: the FreeBSD Ports Collection, for installing from source, and packages, for installing from pre-built binaries

docs.freebsd.org

 

[astyle]

Look at "4.4.6. Installing and Fetching Packages" here:

Chapter 4. Installing Applications: Packages and Ports

FreeBSD provides two complementary technologies for installing third-party software: the FreeBSD Ports Collection, for installing from source, and packages, for installing from pre-built binaries

docs.freebsd.org

Thanks for referring me to the Handbook. I took a look, and realized that there are a couple possibilities:

1. Somebody made a mistake when editing the Handbook. Per pkg(8), pkg add is always local, not remote. The command sequence shown in the screenshot is inconsistent with the manpages, and is frankly, incorrect.

2. Somebody did not read the chapter about package installation completely. It takes understanding the whole thing, not just a snippet. A snippet by itself is gonna be useless unless one knows how it came about in the first place.

Also: pkg-fetch(8) will by default fetch packages into /var/cache/pkg ... you'd have to really use the -o flag to download it to a different directory.

 

[T-Aoki]

Ummm... it's pkg add, not pkg install... The former takes local filenames. The install flag tells pkg to look in a remote repo. And yes, there's a difference - manpages for pkg do go into more detail if you're interested.

Yes, it WAS correct before, but at some point (not sure actually when) the behaviour of pkg install changed.

 

[Beastie7]

Actually the state of technology has never been better when it comes to innate backward compatibility ... we have been using a same architecture standard and instruction set for 20 years which is completely unimaginable for the olden days.

Intel/AMD/IBM/ARM/etc have gone through generations of microarchitecture enhancements throughout the last 20 years. Don't be dense.

So I'm afraid to ask what kind of computer are we talking about, that is getting knocked out of support by obsoleting pieces of kernel in between modern FreeBSD versions. Especially being around retro communities and knowing real people that "daily drive" Windows XP Pentium IIIs.

Just look at all of the target architecture platforms that's been dropped out of support tiers from the FreeBSD Project. This isn't hard to understand. It's not a specific statement.

 

[astyle]

Yes, it WAS correct before, but at some point (not sure actually when) the behaviour of pkg install changed.

I plan to upgrade to 15-RELEASE when it comes out... but at this point, I can only express surprise that there's such a major change in the behavior of pkg(8)... small wonder people are complaining that pkg is unreliable.

Consistent documentation is supposed to be a strong point for FreeBSD...

 

[T-Aoki]

I plan to upgrade to 15-RELEASE when it comes out... but at this point, I can only express surprise that there's such a major change in the behavior of pkg(8)... small wonder people are complaining that pkg is unreliable.

Consistent documentation is supposed to be a strong point for FreeBSD...

I've lost track of, but confusion about change in behaviour of pkg install was seen in this forums or any of official ML.

 

[hruodr]

The command sequence shown in the screenshot is inconsistent with the manpages, and is frankly, incorrect.

I am not sure. As said above, the man page is not clear. It speaks about "pkg-origin|pkg-name|pkg-name-version" and "pkg install is used for installation of packages from package repositories or local archives."

I put chrome alone in a directory, without its dependencies, moved to it and did "pkg install ...". It worked.

It clearly needs more than the ".pkg" file, but also a repository, the dependencies, that is the reason of "cd" I think, but in my case it took dependencies from the internet.

Note that I wanted only to install old chromium and no more old packages, that is why I put it alone in a directory.

 

[astyle]

I am not sure. As said above, the man page is not clear. It speaks about "pkg-origin|pkg-name|pkg-name-version" and "pkg install is used for installation of packages from package repositories or local archives."

I put chrome alone in a directory, without its dependencies, moved to it and did "pkg install ...". It worked.

It clearly needs more than the ".pkg" file, but also a repository, the dependencies, that is the reason of "cd" I think, but in my case it took dependencies from the internet.

Note that I wanted only to install old chromium and no more old packages, that is why I put it alone in a directory.

Yeah, in post #212, T-Aoki pointed out that the default behavior of pkg(8) changed (and I suspect it was a rather recent change) so now it's a pain to figure out if we're even reading the correct versions of the manpages.

And I think that is unfortunate... IMHO, if it ain't broke, don't fix it. Messing with the default behavior of pkg was not the best decision. When software behavior is inconsistent with the documentation, things do fall apart.

 

[drhowarddrfine]

Why Is SQLite Coded In C

Why isn't sqlite coded in Rust?

All that said, it is possible that SQLite might one day be recoded in Rust. Recoding SQLite in Go is unlikely since Go hates assert(). But Rust is a possibility. Some preconditions that must occur before SQLite is recoded in Rust include:


Rust needs to mature a little more, stop changing so fast, and move further toward being old and boring.
Rust needs to demonstrate that it can be used to create general-purpose libraries that are callable from all other programming languages.
Rust needs to demonstrate that it can produce object code that works on obscure embedded devices, including devices that lack an operating system.
Rust needs to pick up the necessary tooling that enables one to do 100% branch coverage testing of the compiled binaries.
Rust needs a mechanism to recover gracefully from OOM errors.
Rust needs to demonstrate that it can do the kinds of work that C does in SQLite without a significant speed penalty.

 

[astyle]

Why Is SQLite Coded In C

Why isn't sqlite coded in Rust?

I'd suggest not poking the bear, maybe... Linux camp is gonna get ideas.

 

[Crivens]

I'd suggest not poking the bear, maybe... Linux camp is gonna get ideas.

Come on - the quoted list pretty much sums up to "never".
The impression I get of the sqlite people is that they know what they are doing and that they seem fun to work with. I'm still smiling at their way to handle the CoC debacle when that was all the rage (pun intendet).

 

[astyle]

Come on - the quoted list pretty much sums up to "never".
The impression I get of the sqlite people is that they know what they are doing and that they seem fun to work with. I'm still smiling at their way to handle the CoC debacle when that was all the rage (pun intendet).

I think that with exception of maturity, Rust is 'close enough' to meeting all of the conditions in the quoted list. I have too much on my plate to want to go through the list one by one and provide demos. However, I just don't think it's out of question to re-imlement SQLite in Rust - Redox OS devs would be quite interested in that, and would probably get someone to pull it off eventually.

 

[LoganGreystone]

I have only been on the forum for a short time and I see a lot of threads like this: "FreeBSD development is going poorly" or "I am switching to another operating system."
The point is that no matter how right the person making these comments on the forum is, the developers do not discuss the system's direction here, so barring a flame war between factions, the changes are not going to be reconsidered.
Perhaps some of the developers on the forum can guide users who open these threads should do, like go to the development mailing lists or something else.

 

[cracauer@]

The point is that no matter how right the person making these comments on the forum is, the developers do not discuss the system's direction here, so barring a flame war between factions, the changes are not going to be reconsidered.
Perhaps some of the developers on the forum can guide users who open these threads should do, like go to the development mailing lists or something else.

There isn't really a place to come up with a technical direction.

Code rules. Actual code contributed sets the direction. It would be of no use to have a committee decide on a direction if nobody volunteers the code.

Top-level decisions are only made in case of conflict between developers, licensing issues and the like.

 

[T-Aoki]

I'm not a developer, but discussions about cutting edge developements including the direction of developements are discussed mostly these 3 official mailing lists. (Archives are linked.)

• freebsd-current
• freebsd-hackers
• freebss-arch

And maybe on committers-only ML that I cannot access and conferences like Euro BSD con, Asia BSD con, BSDCAN, and more and more.

Some are on Matrix, Mastodon, Discode, IRC, ... (I have access only to Matrix and Mastodon). And something that are not fit for open discussion would be proceeded on direct emails.

 

[cracauer@]

And maybe on committers-only ML that I cannot access and conferences like Euro BSD con, Asia BSD con, BSDCAN, and more and more.

Some are on Matrix, Mastodon, Discode, IRC, ... (I have access only to Matrix and Mastodon). And something that are not fit for open discussion would be proceeded on direct emails.

There is a commiters-only mailing list, but it is not supposed to carry such discussions. Its purpose is administrative. Technical direction is supposed to be moved to the open mailing lists when it happens. There are important contributors who are not committers.

In addition to what you listed don't forget the importance of code reviews, all open at reviews.freebsd.org. That's where quite a bit of detail is effectively decided. On actual already existing code, not theorizing.