Back in middle school we went on a trip and saw them doing the deconstruction of the elwha dam. They were around halfway done. We stood on the banks and saw the process of the reservoir turning back into a river. There was around 50 feet of sediment with old flooded trees sticking out. It is hard to overstate the effects these dams have on nature. Seeing the photos of the elwha coming back to life is always awesome :)
Seems the strategy is to eliminate as many numbers/operators before you attempt to guess. Was able to get it in 4 as by the second row I had the set of values to work with.
The missing compositor issue will change a lot I believe very soon. Wlroots[1] just recently landed their scene graph api which enables building wayland compositors with full damage tracking support without needing to touch some of the low level stuff like rendering and buffer management. For example I am currently working on my own wayland compositor and it is super easy to use. Really excited for the future!
[1]: https://gitlab.freedesktop.org/wlroots/wlroots
I think my issue is that there shouldn't be a need for this proliferation of compositors. Wlroots is making that slightly less ridiculous, but wlroots itself is mostly necessary because nobody has bothered creating a WM extension for the Wayland protocol.
I'm not excited. There's no reason we should need dozens of compositors that are mostly identical apart from code that could easily live in a separate process.
That wlroots is getting better at making it easier to build a compositor is a poor bandaid from just removing the need to build a compositor at all.
It's one of many examples of Wayland throwing the baby out with the bath water.
I’m not sure I follow. Is your issue with Wayland that it’s not like x11 with a separate server and window manager? Someone can come along and write that in the future if that’s your preference.
As Wayland is just a protocol itself, the client doesn’t care how it’s implemented. Thus I see Wayland providing the extreme flexibility to implement its protocols how you see fit. Right now wlroots makes it easiest but if in a few years another implementation proves to be better, all those client programs aren’t going to stop working. For now the scene graph allows a whole bunch of compositors/window managers to be easily written that replace x11 ones. And better designs can be further iterated.
Yes. My point above is that one of the barriers to replacing X is that the barrier to writing a compositor for Wayland is far higher than the barrier to writing a window manager for X. And while wlroots is slowly addressing that you're still stuck with the issue that wlroots requires far larger bindings to other languages for example, than what is required to write a WM for X, and is becoming a larger and larger dependency, even as most wm's only want to customise a tiny portion of the functionality of other compositors.
Until there is a compositor offering the same ease, either a bunch of WM's people use and care about won't get an equivalent for Wayland, or it will take a lot more time and effort.
As it is, for example, I'm not moving to Wayland before there's a drop-in replacement for bspwm. River seems to be close-ish to being able to offer something like that, but the benefits of Wayland do not really matter to me and so I have no interest in investing time in replacing bspwm for minimal gain.
> As Wayland is just a protocol itself, the client doesn’t care how it’s implemented. Thus I see Wayland providing the extreme flexibility to implement its protocols how you see fit.
This is true for X11 as well. X11 is just a protocol. But in practice we ended up with a small set of implementations exactly because the pain of implementation was too high, and even most separate servers (e.g. Xephyr for example, or, in fact Xwayland) were often based on Xorg the way many Wayland compositors are based on wlroots.
But that is with the APIs allowing out of process WMs. For Wayland the lack of a WM protocol means you can't avoid a higher proliferation of compositors until someone adds such an API, and it'll hold back development by making a lot of people spend time duplicating compositor code for no good reason.
> For now the scene graph allows a whole bunch of compositors/window managers to be easily written that replace x11 ones. And better designs can be further iterated.
It's great that it's getting easier, but the point is this is the "wrong order" - if you have even a fairly basic WM API very few WMs will care about the scene graph at all. It's like people are intent on ignoring the lessons of what actually worked well with X.
It's really not my problem - I'll stay on Xorg until Wayland is more suitable, however many years that might take. But anyone who cares about Wayland ought to take seriously that the proliferation of compositors will become a nightmare, whether or not more and more of them depend on wlroots, as it means more and more packages to rebuild, test and distribute whenever there are wlroot fixes, for example, for very little gain vs. simply moving the bits that will differ between wm's out of process.
I wrote a blog post on NixOS/home manager configurations with nix flakes. I make sure to link out to other resources for those who don’t have the whole background. See: https://jdisaacs.com/blog/nixos-config/
100% this. The language is designed for its use case which is packaging and configuration (nothing more or less). It has a learning curve due to being lazy and functional but works great once you get the hang of it. But the documentation of all its functions is so annoying. You have builtins and the nixpkgs functions[1]. There is learning the language, and then learning how to use it. Then there is the entire ecosystem of custom packaging functions that have their own pros/cons [2]. The issue isn’t with the language but the difficulty with trying to make existing tooling work the Nix way. That part is where I agree with the curse of nix. But the effort is worth it because once the packaging is complete it just works (forever).
Convenient (version-addressed!) FHSUserEnv is exactly what I want out of Nix. Land me in an environment that has a list of deps (at specific versions, not hashes!), let me go mess with it.
As a heads up they fixed the intel xe graphics sandboxing issue in firefox 96. See https://bugzilla.mozilla.org/show_bug.cgi?id=1698778 It works great on my Framework with NixOS. My about:config settings (taken from my home-manager):
Highly recommend Fastmail. Fantastic server side search and web app (plus has calendar which is essential for an email app imo). There also is nothing holding you back from bringing your own mail client (that can actually interact with the server eg tagging). They also allow connecting to other accounts such as gmail letting you have a single inbox on Fastmail itself.
Favorite “hidden” feature is the ability to do sieve scripting which combined with wildcards and send from identities lets me auto sort emails by path. Eg apps-tech-hackernews@example.com. Also the standard account comes with 100 domains and are real easy to setup.
Been using it for a year now and I haven’t had a single issue. Also the pricing is very reasonable.
