Well, that's embarrassing. Looks like I uploaded the wrong diff. Thanks for your diligence and your feedback!
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Yesterday
Sun, May 5
Sat, Apr 27
Thanks for the feedback. I've merged all suggested changes and also
Looks good to me! Thanks for helping with the rebase. Need to keep in mind to keep those patches up-to-date in the future.
Thu, Apr 25
Fixed line breaks. Thanks for the feedback!
Aaand I missed the other two changes. Now added those as well.
Thanks for the reminder and for the feedback. I've fixed the trailing whitespace now.
Mar 16 2024
Hi Joe, thanks for the feedback. You're right, those changes look pretty arbitrary by just looking at them!
Adding additional notes on the reasoning behind them.
Thanks for spotting those. I really need to run a spellcheck before I submit things. Apologies for the extra round.
Added additional typo and comma fixes and improvements for brevity.
Mar 8 2024
Updated after feedback. Thanks for the great inputs!
Feb 27 2024
Restructured into a bullet point list; certainly better to read - hope the content is correct though.
Valid point on ARM - I've added a suggestion on ARM though I ain't an expert on the topic.
I got those infos from here: https://cgit.freebsd.org/src/commit/?id=47e073941f4e
Thanks for the feedback!
thanks for the feedback!
Feb 25 2024
Feb 23 2024
Added command line example for minimum configuration on VLANs.
Feb 20 2024
Thanks to all of you for moving this along so swiftly! I've already started working on the next iteration. Will post that soon.
Feb 18 2024
Corrected line break.
Correcting section reference to Sx instead of Cm.
Feb 17 2024
Newbie mistake... diffed the wrong way. Updating to diff against main the right way.
Removed FreeBSD <=9 documentation; this also leaked into advanced-networking, because there is a whole section on FreeBSD 9 CARP. I took the liberty to remove that as well.
Feb 16 2024
Combining Ed's and Rod's feedback on processors: removing controversial paragraph on Intel architecture
- Updated paragraph on CPU architecture to reference Nehalem instead.
- Added --usage reference for vmstart.sh
- Fixed disconnect key sequence for cu
Feb 15 2024
Included the relevant feedback points into this latest update. Thanks for the great inputs. Any further inputs/feedback welcome!
And finally condensed the processor feature constraints into a simpler and shorter statement.
Included additional updates after Rod's feedback. Thanks for the inputs!
Sorry, just realized I missed the -U99999; included this now.
Updates after initial feedback - also fixed version of ISO files in the command line listings.
Thanks for the great feedback. I'll update the patch accordingly.
Feb 14 2024
Nov 5 2023
In D34718#926530, @gusev.vitaliy_gmail.com wrote:In D34718#925884, @gusev.vitaliy_gmail.com wrote:I suppose that fixing existing issues and make the code stable is more important for now.
And if somebody feels that snapshot code is stable enough for adding new features, I would say it is not!
You can simply crash host with the following steps:
- Suspend VM
- Run "dd if=/dev/zero bs=1K count=1 conv=notrunc of=${snapshot}.kern"
- Resume VM
That's all. Kernel crashes with panic: general protection fault. Who wants to fix that ?)
Jul 29 2021
Jul 12 2021
thanks for the update. I believe it looks good now!
Jul 3 2021
After reviewing the status, I now realize that I’ve apparently incorrectly uploaded an early diff without a pkg-message to mention the optional dependencies. Apologies for that.
Jun 12 2021
Uploading by using "update diff" always leads to creating a completely new revision. There's no option to update the existing one.
Jun 8 2021
I'm suggesting to ammend changes to remove obsolete integration options.
I'm stupid... there's just no other explanation to how I missed this...
Jun 7 2021
In D30637#689024, @eduardo wrote:Hello!
To remove a review try this link:
https://stackoverflow.com/questions/42618344/how-to-delete-review-request-on-phabricator
Jun 4 2021
In D30591#688012, @dbaio wrote:In D30591#688010, @freebsd_ny-central.org wrote:In D30591#687963, @dbaio wrote:There are a lot of patches that changes NSCDE_ROOT to our PREFIX (some do more than that)... What I want to ask is, are there a way to use less patches? For instance, just replacing the variable value?
It will save time on future updates.And watch out using post-patch target and files/* patches together.
The original install script for nscde puts everything under /opt/nscde; the whole package is set up to be crammed into one directory. Unfortunately, that is not very canonical to how the directory structure under /usr/local is supposed to work.
I had hoped to do it the easy way originally and put everything under /usr/local/nscde or /usr/local/libexec/nscde, but then the documentation would have ended up under something like /usr/local/nscde/share/doc.
Symlinking everything out from that structure kind of felt like cheating, so I distributed things into the locations that matched their use and function (i.e. %DATADIR%, %DOCSDIR%, %ETCDIR% and so on).
Originally, there were even more patches. Fortunately, eduardo@ already pointed out that I respect $PREFIX, which led to some simplification but also meant we still have patch files. Actually, it's a combination:
- first, we strip those NSCE_ROOT combinations and replace them with $PREFIX and sensible paths
- then, from the post-patch phase in Makefile we replace "$PREFIX" strings with actual $PREFIX value
If you have any suggestions on how to improve/simplify this or if we should instead go with the approach of putting everyting into /usr/local/nscde (or similar), I'm certainly willing to give it a try.
Understood and thanks for explanation.
Maybe will be good to ask upstream to help in organizing these structures there (not for now, but on future releases).And what about the INTEGRATION options, is that really necessary?
If you look other x11-wm ports, you won't see something similar.
Jun 3 2021
In D30591#687963, @dbaio wrote:There are a lot of patches that changes NSCDE_ROOT to our PREFIX (some do more than that)... What I want to ask is, are there a way to use less patches? For instance, just replacing the variable value?
It will save time on future updates.And watch out using post-patch target and files/* patches together.