I walk with the dog and sometimes the kids every day, so I see police patrolling around. Had an interesting conversation the other day with the police officer:
- So officer, how have things changed since covid?
- Sir, you won't believe the stuff I get called for. Getting teenagers off their cell phones, wife angry that husband didn't do his share of the chores
- What about what people associate with "crime"?
- Down.
As crime declines overall (it has been for many years now), I believe we really need to rethink the jobs we ask police officers to do. They are hammers and they go into situations that don't require hammering and bad things happen.
Terraform takes a more infrastructure-centric approach and its strength is typically for provisioning infrastructure such as putting up a K8s cluster, etc. than for deploying apps (although you can). Whereas HyScale is aimed at defining higher-level entities in a language that developers understand intuitively without any extra learning curve.
HyScale also aims to reduce the amount of abstraction leakage by dealing with aspects of troubleshooting and runtime operations as well. So this application-centric abstraction enables self-service deployments as well as development on K8s with minimal IT/DevOps intervention.
You can abstract using TF capabilities, they just aren't hidden like HyScale. HCL is widely used, people already use the TF tool, so you end up not having to add more deps and yet another DSL to learn.
It isn't; you gain access to this functionality by building Emacs to use libgtk+ and instantiating the widget via a Lisp interface. (Not sure that's the right library. It might be different these days; I've been building my own Emacsen for a long time now, and I deliberately don't build with GTK or any other widget library since in my early experience that was a fertile source of Emacs-crashing bugs - which, of course, serves also to demonstrate that widgets live in the Emacs process and not outside it.)
No, but it wouldn't work the same. Browsing via a Webkit widget is nice because the browser UI (which is just Webkit, without any of the standard browser chrome) lives inside an Emacs buffer, and you interact with it within Emacs' own UI paradigm as well as from Lisp. I think only Lisp interaction would be possible via webdriver.
It'd be more like the old integration between js2-mode and MozRepl (RIP), where you can drive the browser and send code for evaluation, but the browser isn't part of Emacs in the way xwidget-webkit allows.
Without knowing about the implementation, I can speculate (always dangerous ;-)) that the web browser exploit potential is loading a web page, the elements, html, js, images, nested loading of other stuff. So the danger is some kind of crash in the code that evaluates these resources and then stack-overflow kind of deal gets your machine to do something, kind of like a regular browser risk, and there's no hardening against it. This sounds like a capability I want for emacs though, I wonder if there's some way to make it safer; I could create a separate account and ssh in from my main session and run emacs. If I set my display variable to display from fakeme to real me what xwindows risks do I incur? I've never understood that level.
Yeah, I think the attack surface would be in the integration. The Emacs developers are very good in general, but I don't know if they're well placed to address the security concerns of a browser integration, especially in such an otherwise laissez-faire platform as Emacs. Webkit should be pretty secure, I'd expect, but that only helps until you get to where Webkit and Emacs interact in Emacs' own process space.
You make a good point about X. I don't know a great deal about its security either, and most of what I do know comes from jwz's various salty comments about the risks of poorly
implemented screen lockers. Based on that, and for whatever it's worth, the strong impression I have of X server security is that, for any client permitted to connect in the first place, there is likewise little to none of it.
It's been a while since I looked in detail at Emacs' xlib integration. But it's evidently comprehensive enough for EXWM to exist, and looking at the EXWM readme, I find it's based on a pure-Lisp X protocol implementation. So I assume that anything an X client can ask an X server to do, you can ask an X server to do from within Emacs, and you don't even need that Emacs to have been specially compiled with support for the protocol - you just need it to evaluate some Lisp, and you're off and running.
I think I'll stick with eww for the foreseeable future.
So on regular old linux with xwindows like ubuntu or whatever, suppose I want to use this new deal and also I now don't trust X as well as emacs itself. I create another user that can't SU, and I vnc into a new session, and run dangerous-emacs. You could make the history and text files readable from your main user.
So now VNC is your trust boundary. I should try eww again too.
Every single plebeian on earth wants the polar bears to survive. But their own economic, day-to-day survival is first. These thoughts you have are only for those with the luxury of time.
Edit: so if you TRULY want to help the earth, help your own kind first.
It’s a generational thing. The younger generation has demonstrated they are way more likely to make personal sacrifices to save the planet (look at how they drive less, are vegan more often, and also they say this in surveys)
And somewhere out there today is a penny stock or "sketchy"/high-risk investment that will go to the moon. And it will seem to straightforward in hind-sight, but ignore a lot of other failures.
There are a lot of companies that transform themselves. They start some initial project, pivot, get a cash cow and then follow the market. Some don't.. all the typewriter manufacturers missed the computing revolution. Mainframe to the micro pc etc... Even say, nokia to iphone.
