|
| janjones wrote:
| This is also supported directly in VSCode Dev Containers by using
| just a feature switch[1]
|
| [1] https://github.com/microsoft/vscode-dev-
| containers/blob/main...
| RVuRnvbM2e wrote:
| This is what Flatpak (https://flatpak.org/) is designed for.. why
| would you use docker?
| sascha_sl wrote:
| Because Flatpak imposes some design choices that are... less
| than optimal for porting existing applications, and if you ask
| them to change maintainers will insist this is the way to go.
|
| They have told users that if they want, for instance, Jetbrains
| IDEs to work, they should simply get a Job at Jetbrains and
| convince them to rewrite their entire IDE to support the
| flatpak model.[1]
|
| This is the reason I avoid distros with Flathub enabled by
| default. Half the software on there is broken in some pretty
| subtantial way, and nobody at Flatpak or Flathub cares. They
| really need to realize they're not Apple, they simply can't
| tell everyone to do things their way and hope to build a
| working and reliable ecosystem.
|
| They have the equivalent to snap's classic confinement, but it
| needs to be explicitly enabled every time you launch an app.
|
| [1]: https://github.com/flathub/com.jetbrains.IntelliJ-IDEA-
| Commu...
| AnIdiotOnTheNet wrote:
| Seems like just allowing the user to specify 'unconfined' as
| an override. Then the user would just need to do that with
| flatseal. Alternatively, and with much more needless
| complication, some kind of fuse-mounted /bin directory that
| acts as a portal could be used. Point is there are solutions
| that don't require huge perversions of the Flatpak model and
| also don't require Jetbrains to rewrite everything.
|
| Personally I like that the Linux Desktop community is finally
| starting to wake up to the idea of universal application
| distribution that doesn't require armies of unpaid third
| party maintainers, and while Flatpak is definitely not
| perfect it is, in my opinion, a huge step forward in that
| regard[0].
|
| [0] Not that the idea is really that new, there have been
| many attempts at bringing sanity to Linux application
| distribution, many of them better (IMO), but they've just
| never really been embraced by the community the way Flatpak
| has.
| sascha_sl wrote:
| That's the problem, the flatpak developers outright refuse
| to compromise.
|
| The person I linked above is in fact a flatpak maintainer.
|
| Also, I hate they are shipping broken software. Almost
| nothing in that IDE works properly, yet Fedora now shows it
| by default when I search software.
|
| At least snaps work most of the time.
| jcastro wrote:
| IDEs usually expect/require access to all sorts of things
| on the host, things like vscode can be used to use remote
| container support on the host, etc. but it's still an
| area that needs improvement.
|
| Personally I just layer my IDEs with ostree as a
| compromise.
| throwaway82652 wrote:
| You're under the impression that they can compromise
| here, when this is false. That's a misreading of that
| comment. The "compromise" used by snap is to just not
| have sandboxing at all. Mounting /bin fundamentally
| breaks the sandboxing, it's never going to work. The only
| other option is to change the entire OS to support this
| (and maybe the kernel too), and that's going to break
| everything even more. You'll have the same problem
| attempting to do this in docker.
|
| The main mistake you're making is thinking that Flatpak
| imposed this design constraint, when really it's a
| fundamental property of the underlying OS, that
| sandboxing solutions are forced to work around. It's
| possible to fix this with a distribution built in a very
| specific way like NixOS where you can theoretically mount
| different systems together, but that comes with it own
| sets of problems and things that it breaks.
| sascha_sl wrote:
| If you can't make it work, don't ship it. Please. In this
| instance, not only the Terminal is broken, but also large
| parts of code analysis, task running, compiling,
| testing... essentially all but the editor. And this
| experience is essentially universal. The next app I
| installed had sync support that didn't work because the
| sync working directory was unwritable.
|
| It makes me want to rip out flatpak from every system I
| see.
| throwaway82652 wrote:
| I agree the quality of packages on flathub is pretty
| inconsistent. That part sucks. They're all made by third
| party packagers.
|
| You could make a curated repository but that would just
| be taking flathub and removing a lot of packages.
| moody5bundle wrote:
| I am actually running a few of my daily applications, such as
| firefox, vscode, or spotify inside a podman container (rootless
| makes me feel a little safer). I build a small python script
| around it, which creates a desktop icon, tags the current version
| (so you can rollback), and updates the images after x amount of
| time. I'll clean it up and put it on github if someone is
| interested :)
| ntietz wrote:
| Please do share! I would be interested in seeing it and doing
| something similar (and use podman for the same reason).
| moody5bundle wrote:
| here you go: https://github.com/mody5bundle/capps please feel
| free to open issues and pull requests :)
| moody5bundle wrote:
| I will! cleaning up now and going to publish it later on
| github. The main idea was a least privilege approach to
| running simple desktop applications independent from the host
| OS and being able to control filesystem/network access on a
| per app basis. (spotify on fedora without flatpak or rpm-
| fusion repo's, not even sudo needed to install)
| zozbot234 wrote:
| No real need for full Flatpak, Bubblewrap (bwrap) is
| intended to be a lightweight sandbox providing this out of
| the box, with Flatpak (and other stuff besides) building
| upon it. The Arch wiki has a nice introductory page:
| https://wiki.archlinux.org/title/Bubblewrap
| moody5bundle wrote:
| Oh didn't know about bwrap yet! If i understand the wiki
| page correctly, you still need to get those binaries to
| your pc. So thats why i went with plain and simple
| dockerfiles.
| Proven wrote:
| bogwog wrote:
| Isn't this what Flatpaks are for? Idk if they use podman, but
| they do use similar sandboxing features.
|
| Having a full blown container like this can be useful in some
| scenarios, but I think it's overkill for general purpose apps.
| [deleted]
| moody5bundle wrote:
| i think they use bwrap as mentioned in a comment below. my
| use case is to restrict network access for example. Or
| running multiple firefox instances in parallel (so they dont
| have the same parent process / cookies etc.). or restrict
| memory for to 2G per container. there were just a few things
| i wanted to do that didn't quiet work with flatpak or snap.
| traverseda wrote:
| Firejail is really nice...
| TacticalCoder wrote:
| One advantage one running GUI apps within a Docker container is
| that it is, in my experience, totally trivial to put RAM/CPU
| quotas on piggy apps. Sure, you _may_ put quotas using other
| means but it can get tricky (if I 'm not mistaken it's
| particularly tricky on processes forking themselves like there's
| no tomorrow).
|
| Using a Docker container, which you may already have anyway,
| putting CPU/RAM quotas is a one-liner.
| akvadrako wrote:
| If that's all you want it's easier to use systemd-run and start
| your process as a service.
|
| I do this to put many of my resource hungry apps like FF in
| slices.
| amelius wrote:
| Can you also add bandwidth quotas?
| TacticalCoder wrote:
| That's a good question, I never tried so I don't know either.
| g8oz wrote:
| >> _" This would provide a degree of protection against social
| media platform cracking down on sock puppet accounts being used
| from single setup because traffic is kept separate for each
| account and cookie cross-contamination is being prevented."_
|
| This can also be accomplised by using Firefox's Multi-Account
| Container extension in conjunction with the Container Proxy
| extension.
|
| The Multi-Account Container extension is also great for non-
| dirtbag purposes. For instance testing different user profiles in
| an application - create 1 container for User, 1 for Admin etc.
| pvtmert wrote:
| for macOS, you can use -e DISPLAY=host.docker.internal:0
|
| if docker version is >20.10.x also works with Linux
| mirekrusin wrote:
| Nice article.
|
| ps. you know, for some people it's very hard to read bright text
| on black background. Especially if you're flipping from opposite
| contrast.
| LoveGracePeace wrote:
| Agreed, I bring this up all the time, FYI it's about 40% of the
| population according to several decades of research.
| eurasiantiger wrote:
| The author seems to focus on something called "growth hacking",
| which seems to boil down to social media fraud akin to the
| cyberwarfare psyops various nation-states have been doing.
|
| Fast capitalism, to me, seems to be an ideology entirely centered
| on an authoritarian we-versus-them mindset where profit is king,
| civilian collateral be damned.
| ttyprintk wrote:
| Well, growth hacking is a buzzword for a marketing position in
| a company encountering the steep part of the curve. I suppose
| one of the innovations is that a widget becomes more attractive
| to a segment of the population when you bolt on some social
| functionality, what you're seeing.
|
| At the top of growth is incumbency. I think that's where your
| second paragraph comes in. Incumbents surveil innovations, and
| "growth hackers" don't like to talk about this obvious
| conclusion. They'd rather inhabit a role that concludes once
| growth has succeeded and slowed.
|
| This is no more revolutionary than traditional marketing.
| Marxism talks about capitalist marketing as a way to channel
| alienation among working classes away from collective
| organization. But, Marx from the beginning needed to market his
| ideas to different groups. He needed those groups to realize
| that they needed his political orientation. He tries to do this
| with abstractions, and explicitly gives up on whole classes he
| deems unfit to understand those ideas (the lumpenproletariat).
|
| As the product of a growth hacker reaches incumbency, marketing
| gives way to public relations. We might consider Cambridge
| Analytica public relations hackers. Same level of statistical
| sophistication, same single-focus of corporate promotion over
| all other advancements.
| rovr138 wrote:
| I use some projects that use vnc and also have setup novnc on
| them..
|
| Here's an example of one, https://github.com/accetto/ubuntu-vnc-
| xfce-g3
|
| Novnc just allows accessing things via a browser too. I use it
| for quick checks but VNC when I want a client
| galoisscobi wrote:
| Reading this makes me want to revisit running i3wm in a docker
| container on macOS. After having tried Amethyst (current daily
| driver), yabai, and hammerspoon, nothing comes close to i3wm, in
| my experience.
| adamnew123456 wrote:
| I looked into the equivalent setup for WSL a while ago. The
| thing I could never solve was: how to manage the hosts windows
| via the virtual environment's WM? Without the integration that
| setup is just extra config for no gain.
|
| Because if most tools belong to the VM, then just run a VM in
| full screen and use that. No need to have the display server
| shared if you're using mostly Linux tools that display on the
| VM's X server.
| galoisscobi wrote:
| That's a good point. I'll try out the VM route and see how
| that goes. I mainly just want to tile the web browser, some
| docs, a terminal emulator and vim/IDE and be able to switch
| between layouts and apps seamlessly and VM does seem like a
| good option. Kinda sad that macOS WM is a joke to do all this
| compared to some of the TWMs out there.
| adamgordonbell wrote:
| Of course you can also play DOOM in docker:
|
| https://earthly.dev/blog/dos-gaming-in-docker/
| corobo wrote:
| Additional reading on this topic if you fancy it. This is the
| first one I read regarding docker for GUI apps
|
| https://blog.jessfraz.com/post/docker-containers-on-the-desk...
| phil294 wrote:
| I cannot recommend the mentioned x11docker cmd line tool enough
| for this. It takes care of all possible edge cases, supports
| different outlets (like nxagent or xephyr), focuses on security
| and exposes an easy interface. I'm using it for day to day work
| with VSCode, for example, to fix its atrocious security model, or
| more recently, to try out JPEXS (Java), IDA (wine) and AHK
| (wine). I specially like that this leaves no config or cache
| files left behind.
|
| The article says you need a compatible image for that, but in my
| experience, everything launches just fine.
| stickac wrote:
| Exactly that https://subuser.org does
| ttyprintk wrote:
| Looks like its the only solution in this thread leveraging
| Xpra.
|
| https://www.xpra.org/
| Klasiaster wrote:
| For getting a proper Wayland session I recommend doing this with
| Phosh and wayvnc (WLR_BACKENDS=headless WLR_LIBINPUT_NO_DEVICES=1
| as env vars for starting Phosh and then "wayvnc 0.0.0.0 7050").
|
| You can even have a whole systemd setup in a container using this
| VNC backend, here in this Dockerfile with CPU rendering
| (LIBGL_ALWAYS_SOFTWARE=1) to avoid requring a GPU:
| FROM docker.io/fedora RUN dnf -y update && dnf install -y
| phosh phoc wayvnc sudo socat iproute mutter xorg-x11-server-
| Xwayland dbus-x11 mesa-libgbm mesa-libOpenCL mesa-libGL mesa-
| libGLU mesa-libEGL mesa-vulkan-drivers mesa-libOSMesa mesa-dri-
| drivers mesa-filesystem gnome-shell gnome-terminal RUN
| mkdir -p /etc/systemd/system/phosh.service.d && echo -e '\
| [Unit]\n\ ConditionPathExists=\n\ [Service]\n\
| Environment=WLR_BACKENDS=headless\n\
| Environment=WLR_LIBINPUT_NO_DEVICES=1\n\
| StandardInput=null\n\ TTYPath=/dev/console\n\
| TTYReset=no\n\ TTYVHangup=no\n\
| TTYVTDisallocate=no\n\ ExecStart=\n\
| ExecStart=/usr/bin/phoc --exec "bash -lc \"/usr/libexec/phosh
| --unlocked & wayvnc 0.0.0.0 7050\""\n\ ' >
| /etc/systemd/system/phosh.service.d/10-headless.conf RUN
| systemctl enable phosh.service # Work around a problem
| with a missing dbus.service unit file RUN mkdir -p
| /etc/systemd/system && ln -fs /usr/lib/systemd/system/dbus-
| broker.service /etc/systemd/system/dbus.service # Mask
| udev instead of making /sys/ read-only as suggested in
| https://systemd.io/CONTAINER_INTERFACE/ RUN systemctl
| mask systemd-udevd.service systemd-modules-load.service systemd-
| udevd-control.socket systemd-udevd-kernel.socket ENV
| container=docker RUN groupadd --system sudo RUN
| useradd --create-home --shell /bin/bash -G sudo user RUN
| echo '%sudo ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers ENV
| LIBGL_ALWAYS_SOFTWARE=1 RUN sudo -u user gsettings set
| sm.puri.phoc auto-maximize false EXPOSE 7050 #
| Set up a /dev/console link to have the same behavior with or
| without "-it", needs podman run --systemd=always CMD [
| "/bin/sh", "-c", "if ! [ -e /dev/console ] ; then socat -u
| pty,link=/dev/console stdout & fi ; exec /sbin/init" ]
|
| Use as: podman run --systemd=always --rm -p 7050:7050 imagename
| qbasic_forever wrote:
| Very cool! systemd is so underrated and underappreciated in the
| container world.
| Legogris wrote:
| jessfraz maintains quite a collection of Dockerfiles you can
| borrow: https://github.com/jessfraz/dockerfiles
| timmattison wrote:
| I love the idea of this. I've struggled to get a setup like this
| to work on MacOS though. Which X server is the "right" one to
| use? Which is the easiest? Is there some way to make it work
| seamlessly with built in tools?
|
| As an aside, instead of talking about growth hacking, and OSINT I
| think this whole thing could be a lot more relatable if the
| author chose a simple motivation like privacy. Another comment
| here mentioned subtools (?) which clearly highlights that not
| everything should be trusted with full access to your system.
| FPGAhacker wrote:
| I've used xquartz for this on macOS in the past.
| hoherd wrote:
| It sounds like you missed the x11vnc part of this. You connect
| into the container using vnc, not x11, and potentially via a
| browser based vnc client. If you want to see a working example
| of a gui app running successfully in docker, check out
| https://github.com/jlesage/docker-handbrake
| FPGAhacker wrote:
| the vnc solution was one of several presented in the article.
| The second was using the host x11 server by sharing the
| socket.
| zubnix wrote:
| another solution that allows both wayland and x11 applications
| accessible from the browser (disclaimer: I am the author, it's
| also still very much under development)
| https://github.com/udevbe/greenfield
| madduci wrote:
| I'm doing this since quite a while and I am happy with this
| approach, especially with applications that tend to pollute my
| machine in every folder possible, like IntelliJ:
|
| https://github.com/madduci/docker-intellij
| mellosouls wrote:
| Is Sandboxie still around? It used to do that (containerised GUI
| apps) pre-Docker on Windows very effectively.
|
| Ah (edit), there it is:
|
| https://github.com/sandboxie-plus/Sandboxie
| modinfo wrote:
| And how to launch GUI app from docker via ssh?
| jbverschoor wrote:
| Run X and set the display host?
| ttyprintk wrote:
| ssh -X will do, but in this thread is a project using Xpra.
| Assuming your docker is remote, that's probably better.
|
| https://www.xpra.org/
| adhesive_wombat wrote:
| > This is beneficial for things like social media management,
| growth hacking (either via social media automation or manual
| labour done by VAs) or OSINT investigations.
|
| Ugh, sounds like the software equivalent of using a huge stack of
| ingenious hardware to just do something parasitic like high-
| frequency trading.
| pronoiac wrote:
| Oh hey, I just automated this a bit to run the Linux version of
| Scantailor Advanced on a Mac. I contributed it back upstream.
| It's not too complicated, but it took a while to get it working.
| https://github.com/ryanfb/docker_scantailor
|
| Edit: this method uses xquartz on the Mac side, and socat to
| bridge between a network port and a file socket.
| mg wrote:
| You can also do it with this one-liner:
|
| docker run -it --rm -e DISPLAY --net=host -v
| $XAUTHORITY:/root/.Xauthority -v /tmp/.X11-unix:/tmp/.X11-unix
| debian:11-slim
|
| Then inside the container, run: apt update
| apt install firefox-esr firefox
|
| Now Firefox runs inside the container but displays on your hosts
| screen and you can use it right away.
| ThePhysicist wrote:
| Yes, I think few people seem to realize X Windows can be
| operated over a network as well. I used to do that with the
| Windows Subsystem for Linux to use the KDE Konsole and other
| great tools on my Windows machine using an X server running on
| the Windows side and a few environment variable tweaks on the
| Linux side. My colleagues were always confused when they saw
| the Linux UI seamlessly mixed with the Windows stuff on my
| display. For the use case mentioned in the article xvfb
| probably makes more sense though as that stuff often runs on a
| server and you don't want to stream the output somewhere to
| work with it interactively.
| zozbot234 wrote:
| This is not running X on any network, just sharing access to
| the resources that the containerized app needs to find the X
| server on the same host. There's probably an equivalent
| incantation for Wayland, too.
| nrdvana wrote:
| Well, that's sort of splitting hairs... It is a unix
| socket, which at the API level is the same as a network
| connection, but the kernel skips the hassle of attaching
| protocol headers and routing the packets.
|
| The example above _is_ writing and reading every X11
| message over a socket, and not reaching into /dev on the
| host, else it would need additional parameters added to the
| docker command.
|
| I'm not current on Wayland, but as of a few years ago all
| attempts to run it non-locally required the X11 back-compat
| layer. I have no idea what /dev nodes would be required to
| be shared for wayland to run in a chroot.
| OJFord wrote:
| I found your comment grepping for someone sharing how to
| do it in Wayland, so here it is for the next person:
| docker run -e XDG_RUNTIME_DIR=/tmp \ -e
| WAYLAND_DISPLAY=$WAYLAND_DISPLAY \ -v
| $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY:/tmp/$WAYLAND_DISPLAY
| \ --user=$(id -u):$(id -g) \
| imagename waylandapplication
|
| Pretty simple and reasonable really, just needs to use
| the same Wayland socket and (in order to access it) user
| ID. From: https://unix.stackexchange.com/a/359244
|
| I suppose if you were adventurous you could give it
| whatever other known user ID, and start a separate
| Wayland compositor for it. But I don't know why you
| would, when surely the point is to get containerised GUIs
| visible to you alongside others. Containerised multi-seat
| I suppose?
| bdavis__ wrote:
| thanks for posting this, but I don't think it meets the
| definition of "Pretty simple".
| OJFord wrote:
| It's verbose, but that's why I included the description
| 'just needs same socket and user ID'. That's simple isn't
| it? Of course it'll always need something.
|
| It could be made less verbose by encapsulating in a
| compose file, or by removing the env var to point into
| /tmp and instead using whatever the default is for the
| chosen image. Also it's not necessary to specify the
| value for an env var being passed through with the same
| name (I just copied from SO).
| i_like_waiting wrote:
| So WSL is a must? Because I tried already countless of times
| without that and it never worked.
| [deleted]
| nrdvana wrote:
| You could do the same thing with User Mode Linux or a
| virtual machine. WSL is just the easiest/fastest way to run
| native Linux binaries on a Windows system. If you have a
| X11 server installed properly on windows and can run Linux
| apps over ssh (which I've done with cygwin, but there are
| other paid options as well), then you can run them over ssh
| to a virtual linux on your own host, or look for ways to
| skip the ssh tunnel if they can route packets to eachother.
|
| I'm a little surprised the examples don't require fiddling
| with X permissions, which I always had to do when not using
| ssh.
| nousermane wrote:
| > X Windows can be operated over a network as well
|
| Yes, but GP's example is X over a unix socket. Not sure if
| that counts as network.
| yjftsjthsd-h wrote:
| > Yes, I think few people seem to realize X Windows can be
| operated over a network as well.
|
| Because in practice it generally can't; I'm not aware of any
| Linux distribution not shipping their X server with
| `-nolisten tcp` by default.
| remram wrote:
| This has less isolation. The container has full access to your
| X server and can record your screen or log all key presses, for
| example. It also has access to the host's network interfaces,
| and can access services bound to localhost (even if
| firewalled). There is little point in running software this
| way, if the software is available on the host.
|
| On the other hand the use cases that the article describes can
| already be accomplished by Firefox's "account containers"
| feature or just creating another profile and running `firefox
| --no-remote`
| joombaga wrote:
| The container would only be able to record the screens or key
| presses that occur in the same xserver, right? I never
| thought about access to localhost services. I'm guessing
| there's some xserver configuration that could prevent that.
| remram wrote:
| The parent's setup makes the host's X server socket
| available to the container, so there's only one X server in
| that case. In the article, they run a separate X server,
| which offers some isolation as you note.
| 0x0 wrote:
| Nobody runs more than one X server. And the X server isn't
| involved with other localhost services.
| joombaga wrote:
| I don't intend to run more than one X server. Most of my
| GUI applications don't use X.
| yjftsjthsd-h wrote:
| > There is little point in running software this way, if the
| software is available on the host.
|
| 1. That's a big "if"; I'm fond of docker precisely for fixing
| software availability issues.
|
| 2. It's diminished, but it still provides significant
| protection, since the containerized program still can't see
| the real filesystem or process table without going through X
| or something networked. That's still pretty significant; it
| would, for instance, protect against a Firefox zero-day that
| was being used to read people's private SSH keys (not a
| hypothetical; that incident is what pushed me personally to
| start sandboxing my browser).
| beardog wrote:
| Using it for fixing availability is fine, but I disagree
| that it provides protection.
|
| I don't deny that in theory someone could deploy a Firefox
| zero day that steals ssh keys and that having an abnormal
| setup via docker could throw a wrench in that, but you are
| essentially relying on obscurity of your setup which is not
| an acceptable approach - in the same way that the obscurity
| of TempleOS would not be a good security approach.
| BoorishBears wrote:
| I feel like security through obscurity is the most
| prominent example of the Dunning-Kruger effect
|
| Where beginners in security wrongly rely on it entirely
|
| Then intermediate experts proudly proclaim that it's not
| acceptable
|
| Then expert experts realize it's an excellent part of
| defense in depth.
|
| -
|
| I mean I know it's a hyperbolic example in your comment,
| but do you really think leveraging the obscurity of
| TempleOS wouldn't be an extremely potent way of dodging
| 99.99999% of malware in existence?
|
| Forcing a tailored attack to breach your isolation is
| already miles ahead of just running it on your desktop
| and is most certainly an "acceptable approach", even if
| it's not infallible.
| javajosh wrote:
| _> Firefox zero-day that was being used to read people's
| private SSH keys_
|
| Backup there. I somehow have not heard about this. What was
| the vector? What was the exposure? E.g. have I leaked the
| contents of ~/.ssh to some (hopefully small, at least)
| subset of sites I've visited? Where can I learn more?
| tedunangst wrote:
| https://www.rapid7.com/db/modules/auxiliary/gather/firefo
| x_p...
| tedunangst wrote:
| The container should only have access to the server's
| keyboard input if you give it the magic cookie to do so. If
| you want a secure container, you would only grant limited
| permissions.
|
| https://www.x.org/releases/X11R7.6/doc/xextproto/security.ht.
| ..
| bstpierre wrote:
| Also this method avoids "xhost +" which is a huge security hole
| paskozdilar wrote:
| Thanks, this is much simpler than the original post.
|
| Here's the equivalent Dockerfile + docker-compose.yaml for
| convenience: # Dockerfile FROM
| debian:11-slim RUN apt-get -y update && apt-get -y
| install firefox-esr CMD ["firefox"]
| # docker-compose.yaml services: firefox:
| image: firefox build: . environment:
| DISPLAY: ${DISPLAY} network_mode: host
| volumes: - ${XAUTHORITY}:/root/.Xauthority
| - /tmp/.X11-unix:/tmp.X11-unix
|
| This way you can run it with just: docker-
| compose up
| moody5bundle wrote:
| if you want to remove network_mode=host you need to run
| firefox with the --no-xshm flag
| jandeboevrie wrote:
| This is fun, I did it as well to get an old flash player from
| 2011 working in modern Linux:
| https://raymii.org/s/tutorials/Running_gnash_on_Ubuntu_20.04...
| throwaway69123 wrote:
| Anyway to do this on windows?
| jcastro wrote:
| Distrobox is handy for this:
| https://github.com/89luca89/distrobox
|
| It just lets you reuse any docker image on your desktop (both
| podman and docker), and has some nice features like the ability
| to create a launcher shortcut on the host and transparently
| mapping your home directory. I switched to it full time, all my
| CLI work is just done in a container, and it's pretty
| transparent.
| melony wrote:
| What about in Wayland environments?
| heavyset_go wrote:
| I've successfully used systemd-nspawn with my native Wayland
| session and nested Wayland sessions.
| varbhat wrote:
| Distrobox let's you do the same(using docker or podman) imo and
| is pretty good.
|
| https://github.com/89luca89/distrobox
| AnIdiotOnTheNet wrote:
| Distrobox (or Toolbox) is a nice tool[0], but honestly the
| reliance on Podman doesn't make a lot of sense to me. The
| necessary container functionality is available directly from
| the kernel[1] with little of the complication that Podman
| brings along, and from what I can tell[1] it is pretty
| straight-forward to pull docker and OCI images with simple HTTP
| interaction (or wget/curl) and extract with tar. This could be
| a stand-alone statically compiled executable with no
| dependencies that could work on any Linux distribution with no
| hassle at all, but isn't for some reason[2].
|
| [0] I was exposed to it via Fedora Silverblue, where something
| like it is a necessity since the base OS is immutable. I've
| found it very useful even outside that use case however.
|
| [1] Seems to me you could even use bwrap if you were reluctant
| to use syscalls directly.
|
| [2] having done a little research towards creating my own tool
| because I'd rather not depend on a package that isn't available
| in many LTS distros, among other reasons.
| heavyset_go wrote:
| Truthfully, I think systemd-nspawn and Firejail are better
| solutions than Docker for GUI apps and desktop use.
| 999900000999 wrote:
| I know this isn't the focus of the article, but this license
| provision in a linked project is outright strange.
|
| >By using this software you agree that the following non-PII (non
| personally identifiable information) data will be collected,
| processed and used by the maintainers for the purpose of
| improving the docker-android project. Anonymisation with respect
| of the IP address means that only the first two octets of the IP
| address are collected.
|
| https://github.com/budtmo/docker-android/blob/master/LICENSE...
|
| How can you call a project Apache when you're forcing people to
| pay via their data ? Why is their no opt out option?
|
| Absent that this seems like a great QA automation tool. Or a
| Tinder bot farm...
| detaro wrote:
| According to the documentation about analytics, there is an
| opt-out.
| 999900000999 wrote:
| Where exactly, I'd expect them to both mention the analytics
| and the opt out option in the readme.
|
| Just rubs me the wrong way, you can easily use this without
| knowing it phones home
| metadat wrote:
| Sadly, today this is more common than not, even with OSS.
| Even Elasticsearch has been doing it for many years now
| (since well before Kimchi allowed changing the license to a
| hostile one).
| arghwhat wrote:
| While nasty, the Apache license does not concern itself with
| what an application does, only how it is distributed.
| detaro wrote:
| The especially weird thing is putting something like that in
| the license.
___________________________________________________________________
(page generated 2022-03-26 23:01 UTC) |