Kris said: “Seriously… We all know Vim is the only proper tool to author your thesis :)”
That statement is worth the port over to the “new forums”.
I would like to point out that there is a team behind such decision and it’s not just @kris that wakes up one day and feels like the WebUI “Shell” is stinky.
Also, a while ago there was an entire forum thread about CORE feedback, and the WebUI “Shell” was one of the hottest topics.
1 Like
Okay, that thread was dizzying! But it confirms that CORE is left to die because iX isn’t making enough money. ZFS was/is good on FreeBSD because iX was spending too much money/time on ZFS support. By switching to Linux they offload the ZFS and App support onto someone else thus saving time and money.
I think apps alone will be a mess.
For example: If I want a container for “git” (think a simple git jail I can push pull to). I got to docker hub and do a search (with checkbox filters) I get 432 images to pull from. That’s crazy. Plex; 1581. Nuts!
You thought “TrueNAS CORE apps” were a pain with only one source for the packages? Now there are a ton of different sources to pull from to generate apps from. Good luck. And I’m sure updates will go great.
1 Like
This dead horse has been beaten before.
IIRC, we’ve collectively come to the conclusion that iXsystems wants to be able to offer Apps for home users but only if it entails minimal work and effort re: maintenance since few paying customers use them. I.e. there is no business case other than to entice more sysadmins to try out TrueNAS at home followed by implementing TrueNAS at work, ideally with hardware sourced from iXsystems, with a fat support contract on top for good measure.
In CORE, I seem to recall a lot of Apps being chronically broken, especially whenever system packages were updated. So I can see why the engineering team was attracted to the alleged Elysian fields of kubernetes, TrueCharts, etc. only to discover that the complexities over there were likely even worse re: customer support than with the old CORE jails / Apps.
So now the team seems to be pivoting again, this time in favor of something like Docker, presumably with a “known good” list of distros to choose from. Whether that new approach will ever lead to a stable, functioning environment is a different question. Time will tell. I’m voting with my feet, joined the Jailmaker / Docker caravan for now.
4 Likes
Thoroughly. To the point where there’s nothing left but a faint red stain on the ground.
1 Like
Well … regression … there’s plenty of space!
“Many were increasingly of the opinion that they’d all made a big mistake coming down from the trees in the first place, and some said that even the trees had been a bad move, and that no-one should ever have left the oceans.”
@winnielinnie Where/when does this show, please?
@ALL Anyone confirming this?
It’s easier to explain in a video.
I’ll screen record it.
If I try to explain it in here, people might not understand how to recreate it. (I might try to explain it in a post anyways.)
1 Like
Good point, @awasb. Normally I agree 100%. However, My sarcastic comment about the apps was dripping with venom because I really do see it as a nightmare (more security then maintenance). Inconvenience issues–like updates–are nothing; find a new source, make another. In BSD there is one source where people get apps from, something bad can be introduced but the fact that everyone on that same ecosystem is using that same app means that the bug/hole/issue is more likely to be found and patched. No, not perfect by any stretch (-e.g. the apps are not vetted), but the selling point is that it’s not a free-for-all (more along the lines of: “groups were formed because we are safer together”). I also mentioned dependencies because of security not necessarily maintenance).
@Consantin, thank you for that explanation. RE: feet. I as well, but mine are leading me down a different path unfortunately. I honestly do not want to go down another path but it’s just one of those things that I feel safer doing (I know the way back if need be, but keep a light on).
1 Like
Before making a video, I’ll try to explain it.
This has been a longstanding bug in the GUI (not just in the Snapshots page, but elsehwere), since at least FreeNAS 11.x.
Pre-setup:
- Create a new dataset called
playground - Create a 1 GiB file inside the
playgrounddataset
2a.dd if=/dev/urandom bs=1M count=1024 of=big.dat - Take a snapshot of
playground - Delete the file
big.dat - Take another snapshot of
playground
The GUI bug:
- Visit the page Storage → Snapshots
- Type “playground” in the Filter Snapshots text field
2a. You should see two snapshots in the list (both forplayground) - Expand the first result, and you’ll see that its “USED” value is 1 GiB
- Click the “DELETE” button and destroy the snapshot
- Uh oh! Why does it say the remaining snapshot now uses 1 GiB?!
Did you destroy the wrong one? 
Oh wait, the GUI just sucks…
- Collapse and re-expand the remaining snapshot. Tada! It “redraws” the information, showing you the correct “DATE”, “USED”, and “REFERENCED” values of the remaining (undeleted) snapshot.
This is not the only bug with the Snapshots GUI: It also suffers other issues of improperly “re-drawing” the contents under the entries.
In fact, a similar GUI bug existed in the Rsync Modules page, in which editing one of the modules actually populates the fields with another module’s values. (This was fixed after my incessant uphill battle in the Jira Tracker.)
This is why I feel nervous doing certain things with the GUI: especially with snapshots.
2 Likes
I will leave it to the more sage among us to educate me re: the issues of systemd and other Linux problems vs. FreeBSD. Given a choice, I’d likely stick with FreeBSD but I was lured to SCALE in order to take advantage of the advertised interrupted replication resume feature.
Said feature does not seem to work if the snapshot is large and the ISP is Comcast (i.e. slow). This is why I subsequently inquired about doing the initial transfer via sneakernet as a replication at 10Mbit/s will take weeks to transfer 3TB. Summer weather being what it is combined with the awesome reliability record of Comcast, there will be plenty of interruptions.
@Constantin I don’t know what you mean about the interrupted replication thing (I mean, I know what that is but not the context -i.e. ZSH, snapshot, regular data backups, etc). But have you tried Unison? I believe that is installed on TrueNAS. Also, why doesn’t rsync resume (hence my confusion; I obviously don’t know as much as you so I’m afraid what help I offer will only come off as “stupid”).
Go here and search for “copyprogrest”: raw.githubusercontent.com/bcpierce00/unison/documentation/unison-manual.txt
Don’t get me wrong. I understand you very well. I’m converting to Vanilla BSD to keep current bhyve and jails. (Discussing the ocean part.)
Yeah, I think there will be a few of us doing that. Unfortunate but I guess inevitable (even iX hinted at the possibility with their comment about “die hard BSD folk”). I guess I’d have to be lumped into that camp but it’s really not about Linux v BSD (yes, there is a little bit of that but mostly “not Linux on a data sensitive file sever” type of thing) it’s more about “manageability”. …sort of depressing to just toss out something that was working great.
We still have roughly 2 years but it was nice talking to you guys (in case you or I jump earlier).
Is this fixed in 13.3? 
Currently with 13.0-U6.1…
When checking with the command-line:
When checking with the GUI:
seems to be showing the difference between 
and % complete.
1 Like
Good catch!
Looks like the label is meant to read “Remaining” instead of “Completed”.
But then again, earlier in the scrub, the percentage (“Completed”) was correct…
For example, on a different pool, I started a new scrub, and it correctly says 9.48% “Completed” in the GUI, and also in the command-line.
Maybe the middleware’s math gets confused after so much time passes and it has an existential crisis?
1 Like
I’m not sure that its a bug. Deleting snapshots is not an instantaneous task.
The WebUI reflects the API call. It doesn’t poll the system for changes because that would impact system performance on larger systems.
So, that seems to be a design decision. The WebUI is not a realtime tracker of all system stats.
There will be a standard App catalog of known good images. (Seatbelts)
Anything else is open for users to try. (Unrestricted control)
Each user has to decide their profile.
Can someone confirm there is a fix in FreeBSD 13.3 or a patch that can be reliably applied to 13.3?
We’d like to fix the issue, but we need a 13.3 fix, not a 14.0 fix.