[HN Gopher] Do, or do not. There is no try
___________________________________________________________________
Do, or do not. There is no try
Author : espressoRunner
Score : 509 points
Date : 2023-06-24 18:06 UTC (4 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| diamondfist25 wrote:
| Thought this was the parody like the line from the Rock
| buggythebug wrote:
| Still trying to figure out how to use github
| mikepurvis wrote:
| Looks nifty-- basically it's the "let me try that in a container
| first" except on your live system with no setup to get it going.
|
| That said, as a NixOS user for the last year or so, I think I've
| gotten a bit spoiled by just not worrying about this kind of
| thing any more-- eliminating the filesystem (other than home and
| var) as a big ol' chunk of globally mutable state is so
| liberating.
| rvdca wrote:
| I feel that one day I should write about this curse that NixOS
| brings into your life when you start enjoying it : you cannot
| go back to different systems but at the same time you (at least
| I) cannot vouch and recommend it to others as the languages and
| constructs (Flakes with a space or an utf-8 character in the
| path ? Here is a rabbit hole you can go down with) are just so
| byzantine and painful to work with but oh boy do they work... A
| crystal prison, nice but with sharp corners everywhere...
| rhaps0dy wrote:
| It's the same as Emacs for me. I don't want to leave it but I
| don't recommend it to anyone.
| lovelyviking wrote:
| Why you don't recommend it to anyone? May be a proper
| recommendation is what I need to really be engaged with it
| ? The same for Nix.
|
| Please more details about the practical benefits because I
| kind of see in general why it can be good but there is
| still certain lack of the real practical demonstrations
| from those who use it daily.
| LadyCailin wrote:
| Are you kidding me? Who wouldn't want to emulate an OS or
| play games directly from their text editor?
| Conscat wrote:
| I'm loving Dunnet in Emacs. Nobody spoil me on how it
| ends, plz.
| pxc wrote:
| You mean like this? https://blog.wesleyac.com/posts/the-
| curse-of-nixos
|
| You should still write your commentary on the idea, though!
| paulddraper wrote:
| That's the problem ... So much time to a pleasing but
| inefficient payoff
| vczf wrote:
| Funny you mention spaces in flake paths. I was hit by that
| bug and bumped the PR to address it, and it might be getting
| merged in soon!
| JadeNB wrote:
| > Looks nifty-- basically it's the "let me try that in a
| container first" except on your live system with no setup to
| get it going.
|
| Also, if I understand it correctly, it saves doing a
| potentially expensive operation twice: `try`ing actually
| performs the operation, ready to be committed; whereas, if I
| understand correctly, if you do something in a container and it
| works, then you still have to do it again "normally".
| samstave wrote:
| It would be nifty to save out "try"s in a sqlite/whatever and
| then curl install tries on other systems - such that you can
| easily clone certain setups between machines on a small/home
| network.
|
| Also, if you can name tries, install-stacks - such that you
| can do "Try --name 'homeWebSever' [then do your tries here]
|
| Then go to another machine and from your try repo, just type
| 'try install --name homeWebServer -- and it does whatever
| your try stack was
| JadeNB wrote:
| From my cursory understanding (based solely on the README),
| it seems that `try`s are just directories, so that they can
| automatically be slung around, without any need for a
| backing database:
|
| > Sometimes, you might want to pre-execute a command and
| commit its result at a later time. Invoking try with the -n
| flag will return the overlay directory, without committing
| the result.
|
| Also:
|
| > curl install tries
|
| ... my brain instantly translated that to "curly fries".
| Built-in auto-correct!
| samstave wrote:
| Makes more, simpler, sense...
| throwing_away wrote:
| > eliminating the filesystem (other than home and var) as a big
| ol' chunk of globally mutable state is so liberating
|
| I'm about a week into the (very painful) process of switching
| to NixOS.
|
| This is pretty much the promise of NixOS that got me
| interested, but it seems to be that it's not really true.
|
| NixOS is just running a regular kernel that does regular linux
| security things. If you want AppArmor or SELinux you still have
| to configure it yourself.
|
| If you want a sandbox on NixOS, your options are still
| bubblewrap/firejail, proot, or flatpak. Or of course full
| virtualization with libvirt.
|
| The NixOS "containers" are just systemd-nspawn which (if I
| understand correctly) doesn't really offer more security than a
| properly permissioned user.
|
| I suspect that if you installed a malicious binary in a NixOS
| package, you'd be just as compromised as you would installing
| something malicious from AUR.
| nextos wrote:
| > If you want a sandbox on NixOS, your options are still
| [...]
|
| Exactly, I have brought this up in the Nix forum a few times,
| but developers don't seem to see the value.
|
| Really frustrating and a bit ironic given that sandboxing
| should be quite appealing to a crowd that is attracted to
| Nix.
|
| Guix does implement some a variety of sandboxing options.
| mitchellh wrote:
| The Nix store `/nix` is readonly except by the Nix build
| users. So, if you're using Nix derivations for everything
| (the end goal), then rogue processes cannot interfere in any
| way with files outside of the chroot-like environment the
| build process creates.
|
| The writable directories (your home dir and var, as the
| parent stated) are still "vulnerable" and a program can run
| anything they want of course (bound by typical Linux/Unix
| rules). Nix isn't a containerization/sandboxing technology,
| but it does remove any fear of installing software
| overwriting files you wanted, including OS level (and kernel)
| upgrades.
| throwing_away wrote:
| > but it does remove any fear of installing software
| overwriting files you wanted, including OS level (and
| kernel) upgrades.
|
| I understand that's "true" in a theoretical way because the
| store is read-only and it is all hashed. But the hashes
| aren't routinely checked by some kind of hypervisor, and
| root can still overwrite things in the store.
|
| The "fear of installing software overwriting files you
| wanted" essentially comes down to config file management
| (unhappy accidents) and malware.
|
| You should have config file management in git already, so I
| don't feel like NixOS needs to solve that. I was hoping it
| would solve the problem of random software being able to
| obtain root and not ransomware me, but it practically
| doesn't solve that any better than any other distro.
|
| I want to be missing something. I've invested a lot of time
| learning about Nix for the last week and my system is
| finally working, but I just got to the sandboxing/security
| portion of my install and the threat model seems broken.
| xyzzy_plugh wrote:
| It seems like you misinterpreted the isolation that's
| advertised. There are security benefit but the isolation
| provided is predominantly about deterministic and
| reproducible runtime environments.
|
| There's nothing particularly novel happening at the OS
| level compared to, say, Debian, but the difference is in
| how you arrived at the current state. You're free to
| sprinkle whatever other security bits you are fond of.
| throwing_away wrote:
| > deterministic and reproducible runtime environments
|
| But is there a point to having what you believe are
| deterministic and reproducible runtimes if the
| environment used to build them doesn't protect against
| malware in a build from escaping into the build system?
| zaphar wrote:
| There are multiple non security reasons to want
| deterministic and reproducible runtime environments.
|
| 1. Everything you need to describe and build a project is
| obtained by checking it out.
|
| 2. No more, works on my machine but not yours problems.
|
| 3. No more weird library dependency conflicts.
|
| I've run into all of these and I find them all
| frustrating when it happens.
| throwing_away wrote:
| These are good things and possibly make the struggle of
| NixOS worth it.
|
| But the impression the community gives is very much that
| you can always rollback and everything is in its own
| sandbox, which is sort of true, but not at all true as
| soon as malware happens.
|
| I've never really had a huge problem rolling back an
| ubuntu or arch update when something breaks, so I'm
| surprised at the amount of effort people are expending
| for _just_ this feature with no additional security.
| cookiengineer wrote:
| I can recommend reading the systemd manual entries (e.g. man
| systemd.exec).
|
| SystemD meanwhile has a lot of options for managing a seccomp
| based sandbox, e.g. various protect options for the
| filesystem, mounting critical things as read-only, simulating
| a chroot with its own fake-root user etc.pp.
|
| You can also manage the capabilities of a binary from there,
| so it's actually integrated down the kernel stack.
|
| However, as you mentioned, the lack of an official "profile
| database" for common packages/software makes it just as
| useless as the other tools.
|
| I wish we had a repo where all the things come together and
| people can just do something like "autosandbox apache2" and
| it will do the rest.
| throwing_away wrote:
| Thanks. I'm learning about this today and I'm beginning to
| suspect all the extra isolation software is not really
| useful if you configure AppArmor and SystemD properly per
| service.
|
| The space between "full virtual machine" and "unix
| permission model" is vast and confusing.
|
| I would have thought that because everything is hashed on
| nix, it would be trivial to spin up full "virtual machines"
| without consuming mountains of disk space, but that does
| not seem to be an option.
| dumdumchan wrote:
| Doesn't work on popos: $ try pip3 install
| libdash Warning: Failed mounting /boot as an overlay, see
| /tmp/tmp.BrLiRj0Brb Warning: Failed mounting /home as an
| overlay, see /tmp/tmp.BrLiRj0Brb Warning: Failed mounting
| /snap as an overlay, see /tmp/tmp.BrLiRj0Brb
| /tmp/tmp.c7hp4nI6lE: line 4: cd: /home/user: No such file or
| directory
| korzq wrote:
| Could be related to https://github.com/binpash/try/issues/38
| Could you see if the 'mount-fix' branch works?
| rmorey wrote:
| i really tried to guess what this would be, and couldn't. laughed
| out loud, this is a great idea
| scubbo wrote:
| > i really tried
|
| Well that was your first mistake!
| prpl wrote:
| This would be good with batch HPC systems, possibly both for
| checkpointing and idempotency. I was trying out to do something
| similar with fuse overlays, but had so much issues (2020) with
| this and rootless containers at the time.
| apienx wrote:
| Does it work with SELinux? Asking for a friend. ;-)
| capitalbreeze wrote:
| [dead]
| layer8 wrote:
| What's the catch?
| agumonkey wrote:
| anybody remember Norton Cleansweep ? :)
| chrisshroba wrote:
| Such a simple concept. Not something I'll reach for every day but
| I can absolutely see myself using this a few times a year. Thanks
| for sharing!
| samwillis wrote:
| I think there are some interesting use cases where I could see
| myself using this every day.
|
| Say your a Django developer, using the dev server and a SQLite
| db. Every time you restart the dev server you can easily reset
| to the previous state, SQLite db reverted, any other media
| uploaded or modified changed back. All with no setup, no
| containers, just prepend "try".
| pavlov wrote:
| As cool as this is, it shouldn't be necessary. A proper undo
| turns every command into the equivalent of a "try", allowing
| users to experiment without fear of data loss. Everything in a
| computer user interface should be undoable.
|
| This has been known for over 40 years, but the industry has been
| very slow to get the memo. The undo implementation on the iPhone
| is a weird joke. CLIs have barely even tried (with a few
| exceptions like Jef Raskin's Canon Cat, a textual UI completely
| different from anything else I've ever seen).
|
| Maybe one day...
| code_runner wrote:
| A particular Billy Madison quotes comes to mind.
|
| Cars are cool but humans should be capable of flight, I guess
| only birds got the memo about wings.
| auggierose wrote:
| That made me curious. I think here is an emulator for Canon
| Cat: https://archive.org/details/canoncat
| TheAceOfHearts wrote:
| Agree in principle, but I'm not sure if it's possible to
| implement Undo for all shell operations. But there's a lot of
| existing systems out there, and anything which can be adopted
| incrementally is a big win.
|
| Another shell variation I like is using trash rather than rm.
| ziml77 wrote:
| Fully agreed on this. The simple, default way of doing anything
| should be able to be undone. Hell, years ago Google even
| figured out how to give people an undo button on email! Yes,
| it's just a simple time delay but it makes such a huge
| difference because of how your state of mind changes between
| typing an email and hitting send. Or hell, maybe you just
| accidentally hit the send button.
|
| Undo allows you to make the default behavior for every
| operation to be to just go and do it (or queue it up to be
| done). No need to have a confirmation that the user is going to
| quickly become conditioned to pressing yes on while also being
| just an annoyance 99% of the time.
| ben0x539 wrote:
| I agree that there should be universal undo, but I think by
| contrast the (informally) transactionality of the "try" model
| can be a big deal if your system is concurrent.
|
| If you do a thing, find out it isn't what you wanted, and then
| undo it, while at the same some other process is observing the
| mutated state, that's potentially a much trickier mental model.
| If you undo a configuration change and in the meantime a
| background process has acted on the new configuration, how do
| you roll that back? Rewinding the timeline is one thing, but
| maybe throwing out all the work that happened with the wrong
| configuration is even worse than the status quo.
|
| From the top of my head I am thinking about accidentally
| changing retention windows or bash history max size where the
| data loss is super indirect and you'd have to hunt down the
| undo button for a completely different process, or changing a
| log format so you end up with a file that's mixed json and
| plain text logs.
|
| (Of course, "try" presumably applying the changes in a
| completely synthetic way after the fact could be its entire own
| can of worms in a very dynamic system if there's a risk changes
| are applied in the wrong order or skipping some atomicity
| dance.)
| devit wrote:
| You can implement such a system-wide undo with filesystem
| snapshots using LVM2 or btrfs (or with backup/restore).
|
| However, you also need to properly isolate software in
| containers or VMs since of course doing a system-wide undo on a
| system that is running a server will also revert the server
| state, which is usually disastrous.
| bmacho wrote:
| Undo needs a ton, possibly infinite free space.
| elwell wrote:
| _me trying to figure out how to undo my ping to google.com_
| doublerabbit wrote:
| In theory: the router could capture such ICMP packets, drop
| them. Save them as a pcap and then mail them back to you.
|
| Maybe via a Pigeon?
| klabb3 wrote:
| ping -c -1 google.com
| elwell wrote:
| DO NOT RUN THAT or risk breaking Computer Fraud and Abuse
| Act! It sends a 'reverse ping' _from_ Google to you, and it
| effectively hacks their server to initiate it.
| 2OEH8eoCRo0 wrote:
| Please explain
| sixstringtheory wrote:
| If you rm -rf / you will also remove the undo history and
| script -\\_(tsu)_/-
| moffkalast wrote:
| _me serving google a court order to remove logs with my ping
| in them_
|
| All in a day's work.
| fragmede wrote:
| don't forget all the routers in the path between your
| consumer level Internet connection and Google. Level3 and
| telia need their court orders too!
| kzrdude wrote:
| Hm, what is this "try" command if it's not the first step
| towards a proper undo? I've never seen a better increment
| towards that.
| TheAceOfHearts wrote:
| That's awesome, it feels like an area worth exploring within the
| shell. If I had a magic wand and I could create an ideal shell
| experience, I'd love it if you could soft-execute a script in a
| notebook style environment where each command can be inspected
| and tweaked before committing the change. It feels like shells
| are still incredibly constrained and that they haven't evolved
| that much since the 90s.
|
| The defaults are kind of crazy as well. Every OS should ship with
| a `trash` binary that puts a file in the Trash without actually
| deleting it, rather than recommending `rm`. I get some people are
| perfectly happy to play without guard rails, but I'm sure some of
| us would like a few more guard rails which we can tweak.
|
| I think another similar innovation is how with NixOS you're
| supposed to be able to diff system changes between upgrades with
| ease. Which makes sense, since your OS config is usually based on
| the vendor default with a bunch of changes applied on top.
| kzrdude wrote:
| Linux/Gnome has "gio trash" as the trash command. It's
| available yet mostly unused I think.
| thadk wrote:
| As it happens, the Luke-Yoda phraseology like "Do or do not.
| There is no try" seems to be drawn by George Lucas from the
| popular late 1960s era books by Carlos Castaneda about a
| mentorship (~7 mil copies sold). That in turn seems to be about
| the apprenticeship that Castaneda had with his UCLA PhD advisor
| Harold Garfinkel:
|
| Parallel Yoda quotes:
| https://books.google.com/books?id=pAjYCgAAQBAJ&pg=PT47#v=one...
| via:
| https://www.slate.com/articles/arts/cover_story/2015/12/star...
|
| Thread with 1975 magazine explanation of Castaneda's advisor
| found partly via David Chapman:
| https://twitter.com/thadk/status/1670316860368199681?s=20
| awestroke wrote:
| This is super cool, and I immediately thought of many use cases.
| For example:
|
| * quickly find out which files are touched / installed by apt
| installing a certain package
|
| * find out which log file, if any, a program writes to
|
| * run one of those curl | bash installation commands and inspect
| exactly what it'll do without reading through a huge script
| manmal wrote:
| * see how often a process writes to disk, preventing spindown
| klabb3 wrote:
| Indeed. A cardinal sin in software (in general, not just CLIs)
| is skipping or half-assing documentation of side effects.
| Combined with multi-step operations, partially committed
| operations can be nasty to debug, and even reason about.
|
| This tool can bring a level of control that is typically only
| available in databases and VCSs, and make it a commodity.
| hyperhello wrote:
| I'm afraid I will start trying things, and then I'll forget to
| type "try". Can you make everything automatically try?
| showdeadplease wrote:
| [dead]
| nu11ptr wrote:
| Neat trick. What about commands that impact the running state (or
| other external systems) and not just the file system? Would that
| also be rolled back? Take effect? (I'm not familiar with
| namespaces)
| jasfi wrote:
| This looks something like transactions for devops, which would be
| great. It could make for safer deployments in the future.
| speed_spread wrote:
| The container + temp overlay approach is interesting but this
| could more simply use filesystem transactions, if we had them.
| jez wrote:
| It seems that the focus is on sandboxing file system access. This
| is great if you already know that "stateful disk access" is the
| only thing the command does!
|
| It would be interesting to think about how/whether to extend this
| to stateful network access. What would happen if I used try on a
| command that does something like create a GitHub pull request?
| Right now I believe the pull request gets created regardless of
| whether I commit the file system changes at the end. Some
| alternatives:
|
| 1. Block all network access, because the tool can't reliably
| reason about what could be happening.
|
| 2. Block all network access, except accesses that look like HTTP
| GET requests (and maybe HEAD/OPTIONS requests).
|
| 3. Attempt to build some sort of request replay mechanism, so
| that if a command's results aren't committed, but the command is
| ~immediately re-run with slightly different options, HTTP
| responses for requests identical to those from the previous
| attempt are re-used without making the request a second time.
|
| Obviously all three have downsides in terms of how
| useful/complex/brittle they make the command. But maybe worth
| pondering at the least.
| jez wrote:
| 4. Attempt to intercept network requests, so you can prompt the
| user with whether they want to continue running the command, or
| abort the connection.
| golemotron wrote:
| If there's a mode to prompt on all system / file system
| access it would be a great tool for understanding what a
| command does to the system.
| yarekt wrote:
| Neat! I'm definitely looking for something like this. My use case
| is running semi-trusted dev tools that come packaged. I need to
| run them, but I don't want to trust them, but it's too much of a
| faff to actually check, or run them in isolation (think dotnet
| tooling).
|
| What I would love to see is a blocking IO on reads and writes,
| and network requests. Would let me see if some script is
| attempting to exfiltrate my home dir/ssh/gpg keys.
|
| Not looking to fully secure, just for some more intuition about
| commands/scripts and their dependencies
| gchaincl wrote:
| This is awesome! I wonder if using the same techinque you could
| even even create a pseudo package manager. Once a pkg is
| installed via 'try', it keeps track of its filea ans remove or
| update such a pkg.
| TheArcane wrote:
| Would love to have this on Apple silicon Macs
| EGreg wrote:
| Yoda had no nuance.
|
| And btw Yoda, the elves of Rivendell lived way past 900 and
| looked better than you, so nyeh
| mihaic wrote:
| Interesting. How does it handle if a modified file has another
| change between the run and the confirmation? Understanding this
| case is really my only reservation to try this out.
| lwouis wrote:
| What a wonderful idea. Thank you for sharing this tool
| xyst wrote:
| Interesting. It's like nixOS but for individual fs changes. I'll
| have to give this a try.
|
| off topic: Theranos CEO that was recently convicted really ruined
| Star Wars quotes for me
|
| https://www.thecut.com/2019/03/the-most-bizarre-moments-from...
| samwillis wrote:
| This is really nice! What a clever, but oh so obvious, idea. Love
| it.
|
| Anyone know of an equivalent for MacOS?
|
| Obviously Macs are missing some of the features this uses, but I
| wander if there any alternatives that could enable this sort of
| command on a Mac. I assume the lack of native Docker or
| equivalent is probably indicative of no.
| lanstin wrote:
| I haven't run this command but (editing as this was an
| incomplete thought accidentally posted) minikube and brew's
| version of docker work for me as a complete docker environment
| that works on my (intel) Mac.
| 4pkjai wrote:
| I'm too much of a cowboy for this, but I do recognise this is
| very cool.
| kzrdude wrote:
| try is written in posix shell, it's cowboy too.
| gdevenyi wrote:
| I love that their demo is to finally give me a dry run command
| for pip.
| kzrdude wrote:
| As of pip 23.1, pip install --dry-run finally exists. It will
| still perform downloads but it will dry run the install part.
| jdthedisciple wrote:
| Why are we needlessly illumating all those console background
| pixels to the max?
|
| Anyway, interesting project!
| aendruk wrote:
| Backlit LCDs
| jchw wrote:
| I use a similar approach to have multiple isolated VS Code
| instances each in their own Nix shell, for easier development.
| It's surprisingly effective, and performance is just fine. I'm
| kind of curious how this interacts with Chromium's use of SQLite,
| but I haven't noticed any particular problems.
| [deleted]
| xwdv wrote:
| I thought this was going to be about structuring code to
| eliminate the use of try/catch statements.
| majestic5762 wrote:
| Really really cool!
| jiveturkey wrote:
| Super simple with zfs. take a snapshot. run your command. you
| won't see what it did to anything non-zfs like temp filesystems
| (/var/run and so on) though.
|
| I wish this were possible on macOS. You can see all file activity
| with dtrace but that's not nearly as easy as snapshotting.
| oofta-boofta wrote:
| Cool tech.
|
| As an aside, I HATE the saying "Do, or do not. There is no try."
| Perhaps the best response I ever heard to this dribble was in the
| miniseries where piece-of-human-garbage Elizabeth Holmes is
| played by Amanda Seyfried in "The Dropout".
|
| Professor Dr. Phyllis Gardner, played by Laurie Metcalf,
| responds, "That's all science is: trying."
|
| Have fun in prison, Liz!
| Not_John wrote:
| The title reminds me of my time in a call center. At that time I
| was trying to earn an income working as an inbound and outbound
| agent for a large german telecommunications network operator.
| When I was fired, my team leader gave me the advice: "There's no
| trying, just do or don't do." (in German of course)
|
| I think I had a moment of post-traumatic stress disorder while
| reading the title.
|
| But binpash seems to be a very useful and nice piece of software
| that i will gladly give a try. :)
| slashtab wrote:
| This is what "Elizabeth Holmes" beleived in. I think this is a
| quote from Star Wars.
| Zealotux wrote:
| "If you're going to try, go all the way. Otherwise, don't
| even start. This could mean losing girlfriends, wives,
| relatives and maybe even your mind. It could mean not eating
| for three or four days. It could mean freezing on a park
| bench. It could mean jail. It could mean derision. It could
| mean mockery--isolation. Isolation is the gift. All the
| others are a test of your endurance, of how much you really
| want to do it. And, you'll do it, despite rejection and the
| worst odds. And it will be better than anything else you can
| imagine. If you're going to try, go all the way. There is no
| other feeling like that. You will be alone with the gods, and
| the nights will flame with fire. You will ride life straight
| to perfect laughter. It's the only good fight there is."
|
| - Charles Bukowski
| anonymouskimmer wrote:
| Sunk cost fallacy. And the cause of the continuation of so
| many horrible wars. Take Quark's advice on the third rule
| of acquisition: https://youtu.be/hdQcGzbpN7s
|
| > Never spend more for an acquisition than you have to.
___________________________________________________________________
(page generated 2023-06-24 23:00 UTC)