Yeah for sure, I not make myself clear, i just would say ISO is mandatory for some pentester who work with ParrotOS, i have a dedicated laptop for that, and for all reason Paluniro said i prefer an iso also if i work with some VM.
Thanks for your answer i agreed with pratically all 
So from what I have been able to spend time with, it is very difficult to setup and configure networks, I think the idea with gateway and workstation is a network hop? The documentation doesnt make it clear how to import and configure each. Any other documentation?
p.s.
my opinions are my own and can change with time, as i just want to offer a quality distro to our users.
hmm? maybe you didnt search well:
cant post many links here i dunno why but here i post it:
https://privatebin.net/?ba65ad06595c3da4#68/UnPWweBXSj0x/l4qbu7LYi64rjVW+NUmYNjpWI64=
You only have a few menu expanding options on your docs page for whonix
Conclusion (according what have been discussed):
Whonix development process not familiar with using dockers nor torifying the host traffic with a concrete anonymity solution without damaging it (contributors welcome)
Whonix inside an OS without virtualization security layer, given less security design than whonix current design.
This is why we use Qubes:
Qubes OS: The Operating System That Can Protect You Even If You Get Hacked
E.g Attacker can succeed to break a distro security even when there is a sandboxing availability:
Breaking the Security Model of Subgraph OS
so Whonix Docker left for anyone who want to help building it , current whonix development has no time to focus on other builds.
Thats better for users safety + its very easy way to torify or even VPN everything running inside parrot os.
Whonix only can give help with advises/scripts help/consultationā¦etc. I believe if there is no anonymity then no privacy and if so then there is no security.
brightness and accessories are secondary things and some we dont use them because it posses security threat + having excessive installed programs will increase the surface of attack.
we all do, but depend on the definition of quality.
So its all up to your hands guys, i see whonix out of the scope here as it takes security to the max regardless how it looks like or how difficult it would become if the security needs that.
Thank You! 
Guys please work together. This is a new era for pentesting distro.
Hi @palinuro @Nico_Paul. Another Whonix dev here. We have distro agnostic packages installable for plain Debian. Their benefits go beyond anonymity purposes and would benefit you too:
Others are KDE specific and tune up its security and performance:
https://github.com/Whonix/whonix-ws-kde-desktop-conf
Some our projects like our secure time daemon could see use beyond our distro with a few tweaks. (Making sure an adversary cannot manipulate your clock has implications for SSL security and ensuring no RCE against an old/crufty NTP daemon is possible.
Your reluctance on embracing vitualization for performance reasons is understandable. Though in my experience as the KVM maintainer, running two VMs on your average machine nowadays has negligible overhead (assuming it has virtualization extensions). Benchmarks show KVM as the best performing on Linux. The only limited performance area is 3D acceleration but that will change when this feature is merged in Debian stable next.
Iāve considered containers a while back, but the security guarantees were much less than full fledged hypervisors can provide and so I went that route. Nonetheless if you want containers I can look into assisting on this front.
If you consider shipping Whonix KVM already installed in ParrotOS for people to use optionally, then this has the potential to lower usability barrier for newbies and help adoption.
There are some privacy/security solutions that people from the research community contributed to us a while back that would be useful to you too. The code is feature complete but needs help packaging which we would be grateful for.
Do you know specifically what of the 3D rendering processes is lower? If its anything that could be utilized by say hashcat etc its going to be difficukt to sell that simply due to the fact they are used so effectively when allowed. I honestly need to go find a whitepaper regarding the container vs virt security as i can make arguments in my head that pan out both ways; i know the basics on the differences of course but i can see how each would have a separate set of potential pitfalls. Depending on what would need to be configured and the like i would agree that options typically come with mostly positives, I have a kachine that is not limited on any front so i tend to overlook portability and light resource use but it is a huge factor to 90 % of our users i would estimate so thatās definitely something that would have to be tested to see the viability and at what expense if any it has on the rest of the system. Thank you for some reading material for tonight! Im glad this got revived and i hope we can at least form a long term academic collaboration if not obviously working towards this goal that the thread exists to discuss. Would there be any conflicts or difficulties in regards to keeping up with our update schedule? Its one of the core core core features that invoke such a deep admiration for parrot for many of our users, myself included, i really enjoy that there are typically significant updates versus easier, less noticeably affected ābugsā. If it needs fixed it gets fixed plain and simple (likewise with if it needs explored, we explore it!) i think if whonix stays rather true to those values as well then it would be reasonable to explore at least (not that it hasnt been done, i mean more along the lines of i think (Lorenzo will give you more thorough and accurate information than my brief thought on the matter) I would also rather go āback to the drawing boardā a few handfuls of times before releasing something that doesnt live up to its potential. Again really glad this got revived, im going to get some reading in!
You have a guest Mesa driver as mediator. More info: https://virgil3d.github.io/
Thanks for your reply. Our major release cadence follows Debianās release of stable-next, however we also tend to release in between that time whenever major tasks are completed according to volunteer availability or if there is an emergency security update (upstream apt bug for example).
As for the work on the host (which I think is what would most concern you) it is mostly a done deal once a virtualizer config is figured out. I tend to update it whenever new interesting features come up in the new stable libvirt package or to tweak settings for more security if I come across advice in research papers.
I have no problems figuring something out on the host side if needed.
A wise motto indeed. Also one which we tend to follow thanks to an active userbase that brings such problems to our attention 
Well we can both be happy with at least being a step closer as we plan on supporting a Long Term Support that is based on Debian stable as well! You can find some more info under the release notes of 4.3 on the Parrot Blog, with more to info to come! 
It happens on virtualized systems too, as many vulnerabilities allowed an attacker to exploit guest syscalls to the host system inside kvm/qemu, virtualbox and other major virtualization platforms, but probably it is way easier to break a container than to break a VM.
I think we are on the same track here.
We configured the system to prevent the startup at boot time of all the useless services by default, and it reduces not only the boot times and the memory footprint, but it significantly reduces the attack surface as well.
The security edition of parrot, which by design is meant to provide A LOT of pre-installed tools and services, exposes zero opened ports at boot, and all the services are frozen. Parrot Home and Parrot Security have the same programs running and the same memory footprint (and network exposure), and all the security tools and services (and their dependencies) are just dormant and disabled.
Our projects are on completely different rails, but i believe we are both going in the same direction.
For this reason i would like to re-open (or at lease try to) this discussion once we finish our conversion from a rolling release model to a more reliable LTS model.
Another big news for you is that we are starting to do a little audit on whonix to get familiar with your code, test your patches, read your code and eventually try to improve it as possible.
I am up to start this little audit session with the security club of my local linux user group here in Palermo.
THIS IS A VERY GOOD NEWS!
i donāt have enough spare time to take a look at them by now, but i absolutely have to add it to my todo list for the next months.
I would also like to share our firejail configs with you as previously promised in another thread.
I wanted the firejail configs to become a standalone package (as some of you suggested) and iām working on it.
Itās not just a matter of performance impact (as you said kvm is very well optimized), but itās also a matter of flexibility. If we close every single process inside a kvm container, then programs canāt easily interoperate with eachother, it is very hard to merge them into a single workspace and none of us here at parrot os are capable of doing something better than qubes os.
We wanted to adopt containerization over virtualization because it adds a easily configurable and pretty decent level of confinement at an application level, not at a context level, and firejail allows us to to it with zero overhead, where overhead does not just mean cpu time, but also memory footprint, storage resources, network access etc.
Choosing an application level isolation system based on containerization over a context one based on virtualization offers another interesting feature for cheap: by closing an application into a VM does not automatically offer you a proactive defense against unknown exploits, like memory execution protection, syscalls limitations, controlled network access, filesystem isolation enforcement etc. instead you just create a virtual machine where the isolated application behaves identically as before, but now it damages another system instead of the host one, and any additional safety measure has to be taken apart in a way which is not related to what virtualization does.
The containerization technologies on the other side offer fine-grained control over what a containerized process can or cannot do on both the host system or the guest overlay.
Do you want to deny file executions in the home directory for that process? do you want to enable write-memory protection? do you need that process to not exceed a specific amount of memory? to allow only tcp traffic? to allow network routing to a different gateway? do you need to exclude some resources to the process? do you need to expose a completely different filesystem instead of reusing the original one? all of these goals (plus many many more) can be achieved by just writing an instruction in a config file.
I am not saying that containerization is safer than virtualization, or that process isolation is better than context isolation. I am just saying that these are different levels of the same technology, and the only way to achieve a decent level of security is to mix them in the proper way.
I see Parrot as a good brick to be used for a specific context, and virtualizing multiple instances of parrot for different isolated contexts would be an awesome way to isolate things.
Every context would be isolated from the other in full Qubes OS style, and every process of the same context would be not only isolated from the other, but its capabilities would be limited too.
I believe that opening a malicious pdf inside a kvm machine is NOT a secure way to open that pdf, while disabling memory execution network access, unnecessary syscalls and limiting filesystem access is a better solution. The combination of the 2 worlds is just sublime. I, as a parrot developer, am focusing on what happens when the kernel runs a process and how to make the system secure from that process and that process secure from the outside world, all of this on an almost general purpose distro with a pretty famous pentest edition. Qubes OS is doing an awesome job on both my field and context-based isolation with a project with only one goal: to provide a system as secure as hell. I think that you at Whonix are working on another important field, which is how to make network communication private an anonymous and how to keep the system as secure as possible from the outside (without being a firewall of course).
none of us is ready at the moment to co-operate in a practical way because none of us are actually working on the same bricks of the whole thing, but we have a lot to share eachother and a lot to experiment by merging our worlds and seeing what comes out.
P.S.
i wrote this shitty wall of text in a hurry at late night, sorry if it is not so immediate to understand (or if it canāt be understood at all)
makes sense more than ever , please keep it up
once you finish the TLS and/or has some additional points please write them here so i will be notified .
side news
we finally provided .ova images. the build process is not automatic but people seem to like it a lot
very great job! i have downloaded and installed the image but for some reason it has some issues to run mostly with network interface. i dunno if thats been reported or not
done 
i like your awesome horny community every day more and more !!!
it gives me hope that we can create all together a space (distro) in which it is normal to be able to speak freely and we value again on our data and private sphere (sorry for my english )
KEEP ON GOING!!!
great! , we can overcome this by Whonix GateWay (minimized as GW). either by built-in bridges , customize/manually adding bridges , and they can obtain it from the bridges server which is newly feature implemented in TBB and so as in GW we gonna have it. we use Anonymous Connection Wizard (ACW) to control Tor connection in the GW
Are you guys still planning on making something to help with anonsurf in parrot? It would definitely help some of the users that are unlycky geoip wise with living in countries where they need to use bridges and def cool if it could be something that just starts or something like that maybe