This might be paranoid, but if I go to a website that might not be 100% secure, can they tell what is inside my hard drive desktop’s PDF or what is inside my images on my hard drive?
I have a Chromebook and as well as a Windows machine.
Could anyone point me to resources that might help me find an extremely energy efficient Mini ITX mainboard? I have no clue where to even begin (or how to compare products), given it's such a complex field and I know little about hardware specifics
Hope this is OK to ask here, I don't really know my way around Superuser that well!
It's for a mini workstation that I'd be using 8-10 hours a day under varying load (some programming with giant IDE open, some graphics with Photoshop/Indesign open, no fancy 3D stuff). I live off the grid, with solar panels charging a number of batteries, and I'm looking to put as little additional load on those as possible.
I'm currently using a Macbook Pro but want to go back to Windows for cost reasons and reasons of protest (apparently starting this year they're putting a software lock on devices repaired outside of Apple and that is the red line for me.) The MBP is pretty energy efficient and I'd like to replicate that with a desktop PC as far as possible
@JourneymanGeek I have a really cool looking case in my sights that is Mini ITX, but would be open to other suggestions.
@JourneymanGeek yup, looks like there's no way around M.2 (and perhaps a normal 2.5" one for storage, IF there is a way to turn them off when unneeded. Otherwise, external.)
@JourneymanGeek Indeed! :D Had no idea about K, definitely will not need this.
@JourneymanGeek To be honest I'm not sure. My idea was to try using an onboard chip first and see how it works out. I don't do much 3D stuff but do edit gigantic graphics files (with complex Photoshop brushes and such) and documents in Indesign. Can't imagine them needing a GPU much but don't know exactly.
@JourneymanGeek Yeah. Ideally I'll find a mainboard that comes with a decent graphics chip that I can give a try, while keeping options open should it absolutely not work out
@JourneymanGeek Heh! Yeah I think I got my first Macbook around that time and stopped caring :D although I wasn't that much of an expert in this previously, either.
@djsmiley2k yea, each container has its own network namespace. I've not noticed any interference between them
by default it creates a managed bridge (macvlan in newer versions?) that nats to internet and each new container gets one eth on that bridge, but you can define additional eth devices for specific containersand bridge directly to external network, etc.
@djsmiley2k @HornOKPlease probably knows more; he introduced me to lxd
Pit interview: "What can you tell us about your robot?" "Well, it's a printer. It can do about 5 pages per minute."
"Your opponent has said they aren't vulnerable to flips because of their srimech, what will your strategy be?" "Honestly Philippa, I've no idea. I might print some fliers on robot pacifism."
@Bob @djsmiley2k with root access in an LXD container, by default none of the LXD network setups would prohibit guests from maliciously attempting to claim IPs you don't want them to. For instance, if you have access to a public internet /24, you can't, by default, restrict which IPs within that a guest can claim from the host side, nor which MAC addresses it might try to use.
So if we assume the iproute2 scripts are maximally damaging (by accident or intentionally) they could, worst case, break networking on your box
lxc doesn't even virtualize networking at all, IIRC
it's only lxd that even tries to
but it's nowhere near as safe as OpenVZ was, or Solaris Zones / Crossbow, or proper hypervisors
also I think with the default setup (I.e.not bridged to a physical interface on the host) you can't claim an external ip
if you do create a bridge to a physical nic, well, yea, that's a full layer 2 bridge
the interfaces themselves and the corresponding routes/tables should be fully namespaced
the wrong bridge setup would effectively punch a layer 2 (but not route entry!) hole through; if you need something more restrictive you'd need to look at the p2p nic and somehow forward filtered frames?
oh, analogy
bridge to physical is just like a vmware bridge, which is just like a separate pc plugged into the same (unmanaged) switch
oh lol
@HornOKPlease they added a security.mac_filtering
so even that's already sorted
> Prevent the container from spoofing another's MAC address
@HornOKPlease I remember Linux-vservers... shutting down one container would kill networking on the host
@Bob somehow macvlan works kinda similar but kinda different from a bridge... you can still have multiple subinterfaces in the guest that claim different external IPs
