Brennan Novak [1]:
> @adrelanos I notice you keep using the term `TemplateBasedVM` in
> cases where I would use `AppVM` is the term you're using the
> preferred term? Upon getting familiarized with Qubes & the Docs, it
> seem AppVM was the term used most often. Perhaps we should
> synchronize and use just one term so as to not confuse new commers?

I keep using TemplateBasedVM because it's my prefered term. Because
AppVMs, NetVMs and ProxyVMs are on the same level. Imho it's wrong to
call a ProxyVM an AppVM. A ProxyVM can either be a StandaloneVM or
TemplateBasedVM. An AppVM should not imply TemplateBasedVM, because one
can easily check "standalone" for AppVMs. StandaloneVM or
TemplateBasedVM is a different level. The distinguishing is important to
me. I always try to carefully word my messages to avoid confusion.

After agreeing on the current technical implementation (I of course
admit, I could be wrong about something), I am very much for using
synchronizing good terminology. I am a big fan of that. As it stands
now, however, I don't think I misused the term. Happy to be corrected!

Thanks Brennan, for raising this!

Cheers,
Patrick

[1]
https://github.com/QubesOS/qubes-issues/issues/1084#issuecomment-124992784
[2] https://groups.google.com/forum/#!topic/qubes-users/byGsQryrBxQ

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 07/27/2015 11:02 AM, Patrick Schleizer wrote:

> I keep using TemplateBasedVM because it's my prefered term.
> Because AppVMs, NetVMs and ProxyVMs are on the same level. Imho
> it's wrong to call a ProxyVM an AppVM. A ProxyVM can either be a
> StandaloneVM or TemplateBasedVM. An AppVM should not imply
> TemplateBasedVM, because one can easily check "standalone" for
> AppVMs. StandaloneVM or TemplateBasedVM is a different level. The
> distinguishing is important to me. I always try to carefully word
> my messages to avoid confusion.
>
> After agreeing on the current technical implementation (I of
> course admit, I could be wrong about something), I am very much for
> using synchronizing good terminology. I am a big fan of that. As it
> stands now, however, I don't think I misused the term. Happy to be
> corrected!

You a re right.

those are two separate property

By usage/connectivity:
- - dom0
- - domU
  - netVM
  - ProxyVM (or FirewallVM)
  - AppVM
  - Disposable VM (or DipsVM or DVM)

By 'storage':
- - Template based VM
(while this is the default VM type in Qubes we rarely use this word)
- - Standalone VM
- - Template 'VM'


And we have more:

By virtualisation technology:
- - PV  (default)
- - HVM


Maybe we should include such a categorization here as well:
https://www.qubes-os.org/doc/Glossary/



- --
Zrubi
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVthPpAAoJEACyhZsQIQUVRCcP/ibwAdb7Jy8uRuJV8qVe2qOU
OP/ediQbwqNGVhJ+6CvAFw1Pwkud4aRz0cA2alCQyzMEY7mIhMjelMe+hbiCO7Hu
tOOxw6N2/4aReFs7e5yjgiu2qPiHC/9HS/PKWPLc7ysOCmVUfPAulcAtG5KPOhIE
W+ZihvTCEEk11xNCL7L17o26AOMVJ59cVyCkz2oOFec2SbmQI4SMucHJzjgnkV6o
S1qdP3U444n4BfYkgQS62Qw666LnxIsPbSoPyxoGZvp/iZSta+eOmUFJaO8gOlYr
HDUFkv7tHGxFhlsq20120oYQtxP/cMIOrbNK4a2McTdJvbKm4ugQ8+PjfjN/uSzs
TLSfAX3ETQKT0XdzGOC0uzQne3d9O+HWZJlH0YNAJETTTow691VSDU0T6QgKGl3c
YkrBPPN/mSJbWhYImjmDOCQTBYPr/TpXrht3zjlSpn2b2ysixbBrqJBkB1vP5s5T
9S9tNn7n+EcKR9jCo1+ijw6gRF1CH7/IOFYmdsncmhR6SmvVxr4anNacT+pvSG77
eP1HR3E24CAMNukog3dZgI12QoNcEUp4Xh62V/xAWZpP0CfOSS/OJD+ckYt5A2z9
HxPELdi6LxxTtXfOkYko0vv0Orn8WqHdpp3ObaL56nFZmVb93qa/u5b7nHfZVVU3
TEkh2pVLo/ECI7iLqFxn
=gokx
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Heya Patrick, thanks for clarfying. I see your point about the 3
different types of TemplateBasedVMs and how as a "correct" level
of abstraction it is definitely the most apropos term, especially
in the case you mentioned. However, I think my point still
stands- the official user docs make no mention of that term.

Perhaps they should as it's an important abstraction to be
understood. And, perhaps in the future when expressing concepts
like you were (in OP) it would be best to express it like:

 - `qubesdb-read /qubes-template-type` -> `StandaloneVM`
 - `qubesdb-read /qubes-template-type` -> `AppVM` (or other TemplateBasedVMs)

or

 - `qubesdb-read /qubes-template-type` -> `TemplateBasedVMs` (AppVM, ProxyVM, NetVM)

I'll be reviewing the docs and thinking about this more soonish!

Cheers,
BNVK

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVu2TFAAoJELgSf1EkRiQh+s4P/iNhhvOo4BxyTu3LG5JI4OmH
GWSAX9UDPG+R1YpwFDrMevNm3YGyjrMIJ/0GD8IoBPSq95hJgK31DhJ83GFHZapa
1QNDSkuTHsKP7/dcOzDluh6pm40SLgvvpdBSoI3+aapP4yMZ0Two7lEBSPDIPo9t
x7SDoy3xxd8Q8bfbNTOl5Q1ry8IejwgwKINtw2eS6pOkPOhAZqVN9YZ9/MZIHD5n
/WdZOin9S9BHDCJfeKzGgz8VJlAJbBe+bJGFQAt8EtiqswV6wQB3AxQRxhho/77n
jglVlqsN70pPtLeW/VYN1cd4Q64LwlEbOYnnIxtWS6p/+m2hMbWhwyAf5MAIb8F1
D1t7zI6TS7pGVryBI3C5ovPwWvoVaehyTsyXmiuKP3nAZoQtJDn2QlzAaMYSBciT
Sfih4FEVy6GVefrqPjfURBIIns/bjCjgBPg7cHQAI7JuUXsXAMKvxUMUmkxNS0ay
UrCZA17hnwZYXGHMaC0I9WphdZuMZcx9+WwtNbgTowXxzZa/8p8KWk0d3NtpYQ1Z
spYBOZ6nD++umG08CEA5/g9VqfXyzFgcOL2qscEIpYu489K32fsNmLGzYLQd1uIL
bKnAlK2le1WUrNPYI3mDJh8+vWST4tqt3sAWaguTE6CJr6vjqZpqcXdAFJn8Hb83
IM9GVwUE87r7legX/aIj
=MK8i
-----END PGP SIGNATURE-----

Brennan Novak:

> Heya Patrick, thanks for clarfying. I see your point about the 3
> different types of TemplateBasedVMs and how as a "correct" level
> of abstraction it is definitely the most apropos term, especially
> in the case you mentioned. However, I think my point still
> stands- the official user docs make no mention of that term.
>
> Perhaps they should as it's an important abstraction to be
> understood. And, perhaps in the future when expressing concepts
> like you were (in OP) it would be best to express it like:
>
>  - `qubesdb-read /qubes-template-type` -> `StandaloneVM`
>  - `qubesdb-read /qubes-template-type` -> `AppVM` (or other TemplateBasedVMs)
>
> or
>
>  - `qubesdb-read /qubes-template-type` -> `TemplateBasedVMs` (AppVM, ProxyVM, NetVM)

I guess to make this understandable, qubesdb-read would require new
keywords.

For example to express `Standalone AppVM`, I would have to use the
following.

`qubesdb-read /qubes-vm-type` -> `AppVM`
`qubesdb-read /qubes-vm-updateable` -> `True`

For example to express `TemplateBased AppVM`, I would have to use the
following.

`qubesdb-read /qubes-vm-type` -> `AppVM`
`qubesdb-read /qubes-vm-updateable` -> `False`

Not very well understandable. The keyword `/qubes-vm-updateable` is
rather nonintuitive.

Cheers,
Patrick

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
It was designed to mark VMs where installing updates makes sense (->
will persist across VM restarts). Any better idea for this flag?

Maybe additional entry like `/qubes-base-template`, which would contain
name of template on which the VM is based (in case of TemplateBasedVMs),
or empty string (no key at all?) in case of standalone VM/template. This
will also implement your request of template name for some messages in
Whonix. After some consideration, VM already has ability to get the
template name (for example from logs), so this will not pose additional
data leak.


- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJVvoBlAAoJENuP0xzK19csb6gH/jG1DYzgt11vGZfsUyxU1gHx
1DYgXMVT3HewPIfU3xGWT34OP1F0xOLVXsXA+wmfY2Uyw86XULRV3eRHMZDRMsnv
b+0h/vFpiYxO7QXvV1Ebda1v0cQZozxV+qkBlngbBh+fpgOHV4nalBiO4n4d0f8L
C9tI2fDfB5xeay242mxZxxSEhU2dnd0ZHZhM+BQHiZwd87Hj3JRnnHDrTikrwDFc
XIzfBhPMMbPNvSr1akJhVkkSQV3Do5A/rczneBnG71a/s6f+l5SoHb6omMuGC1w9
WfplTr1lwib8BfbdrbB31rDT75N5DEIr4I46jQJCa1QpK9WY7selYumvZkAkEUw=
=3c/7
-----END PGP SIGNATURE-----

Marek Marczykowski-Górecki:
updateable implies a relation to package management.

Hard question. Let's see. What about...

`/qubes-vm-persistence` ->
- `full` (fully persistent file system, same for regular installed
operating systems, output in TemplateVMs as well as StandaloneVMs)
- `QubesTemplateImplementation` (limited persistent as per
https://www.qubes-os.org/doc/TemplateImplementation/)
- `read-only` (for Live DVDs) (now now, perhaps extended some time in
future)

`QubesTemplateImplementation` is a bit bulky. Since I am not aware of
similar implementations, I don't find a label to express this. The
closest similar implementations coming to my mind being Debian Live
persistence and Tails persistence. Please anyone feel free to come up
with better suggestions.

> Maybe additional entry like `/qubes-base-template`, which would contain
> name of template on which the VM is based (in case of TemplateBasedVMs),
> or empty string (no key at all?) in case of standalone VM/template. This
> will also implement your request of template name for some messages in
> Whonix. After some consideration, VM already has ability to get the
> template name (for example from logs), so this will not pose additional
> data leak.

Yes.

> empty string (no key at all?) in case of standalone VM/template

- Not no key please. (Makes using this in scripts harder.) Empty string
perhaps.
- Maybe the string could still be set to something useful?
- StandaloneVMs -> examples, `descendant-of_debian-8` (when created from
a TemplateVM) / `custom` (when manually created)
- TemplateVMs -> `base-template`
- TemplateVMs can be copied. -> `descendant-of_debian-8`
- (Unless this causes a lot extra work / complexity.)
- Minor importance. Not sure, I am building a bikeshed here. ;)

Cheers,
Patrick

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I don't think `read-only` is an option here. Linux doesn't really works
with read only file system nowadays. There is always some copy on write
layer (or a couple of symlinks) in such case. Actually template based VM
have read only access to root.img (as /dev/xvda) and COW is set up in
its initramfs.

So maybe:
`/qubes-vm-persistence`:
 - `full` - standalone / template
 - `rw-only` - template based (it's reference to /rw, since it isn't only
   /home)
 - `none` - DispVM

> > Maybe additional entry like `/qubes-base-template`, which would contain
> > name of template on which the VM is based (in case of TemplateBasedVMs),
> > or empty string (no key at all?) in case of standalone VM/template. This
> > will also implement your request of template name for some messages in
> > Whonix. After some consideration, VM already has ability to get the
> > template name (for example from logs), so this will not pose additional
> > data leak.
>
> Yes.
>
> > empty string (no key at all?) in case of standalone VM/template
>
> - Not no key please. (Makes using this in scripts harder.) Empty string
> perhaps.
> - Maybe the string could still be set to something useful?
> - StandaloneVMs -> examples, `descendant-of_debian-8` (when created from
> a TemplateVM) / `custom` (when manually created)
> - TemplateVMs -> `base-template`
> - TemplateVMs can be copied. -> `descendant-of_debian-8`
> - (Unless this causes a lot extra work / complexity.)
> - Minor importance. Not sure, I am building a bikeshed here. ;)

Standalone VM (or template) is really standalone - there is no
information from from which VM it was cloned/created (if any).

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJVv0cYAAoJENuP0xzK19cs3P4H/0sB/suND+vVBAkFyYkHXnnC
ODgYzs6L1syGtCT44vvdhXp2K+quC6PDmfD0lXALpU+ZNhjxWdQZaJ5yrsmtjK1u
yJkEWCbbZej4FpIjAIejCzgoDlEZxrlIUWJfjORdunFPN0eWiIQSwL29k2VARMHv
TXVBmel9toGzo3LOSiX+8IWo+AaF60rBZD5gmpyIXm0HEtKPi3Z6N/Al4SAGepR4
PUuRws2NJJcKmIUyfcYWTuGOn7WQdIVu0ICjwOR9w7FAMDEMiepnc3vgiZDB78d0
dTUPN2fLlOzX1+O4qUMVEgVgTwHgs1RXQ4p2bejEyivbNDM1DKxO3Q5gYrrlhvc=
=p+2j
-----END PGP SIGNATURE-----

Marek Marczykowski-Górecki:
Alright.

Cheers,
Patrick

'TemplateInstance' comes to mind, but TemplateBased is just as good. If
you want to show template name as a value, then 'BaseTemplate' might fit.

The thing is, you're committed to providing a functional classification
that handles netvm, proxyvm, appvm... but 'template/standalone' isn't
functional but an administrative classification. Two properties like
_funcType_ and _adminType_ together would probably give you the
expression and flexibility you seek. For the latter property, any value
beginning with 'template' would indicate a read-only root filesystem.
You could also use it in future for new admin types other than template
and standalone.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Take a look at further mails in that thread. This has been already
sorted out and the outcome is here:
https://github.com/QubesOS/qubes-issues/issues/1101

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJWAIfsAAoJENuP0xzK19csKDwH/3DD/LlDmlF4lOAk77XJ2lFK
LDickqXaUc83GvmruTJ3U1jrsY82TUHIsRPQghTWdxujwPc/m77yiiIeXV4hk2u5
0mJnEvEmnyujVopCbKub431jwfuO66ttmK7Go3mxxCEgrcmqIgnvqtWXcaOcBW0X
kazWYfIeNs3hjFgUbGJvaOmglJylnUJFfTbdExQ9c0sV6OAhElq4OTSHyasB5H1F
XZLqasLB0Jj8tgeTXM3E8tibxOMHVBw4dtFBeAF8SseZD3uKFM3+Y04QF+/CNMP7
w5gIXMmGGYoFz1sQV2ZvLxSw/E26QmrNGwOnM1KdjKgIEXUdYV4tm8qe4y9GdA8=
=Q7sO
-----END PGP SIGNATURE-----