I think in a podcast or so just months ago, he talked about how he planned for Infections to stay in the race for next few years, and seemed to be excited about it
Does this imply that around 110 CVEs listed in the CISA KEV list are not (probably) really exploitable or doesnt have enough public information to enable a potential hacker to exploit them?
Counter-review: the level of control is unmatched, but it's a little too extreme, I feel. Even something as simple as a volume widget isn't included OoB. Yes, there are libraries of widgets out there, but not many -- and not always the best quality (memory leaks are unfortunately common, seems to be a screwy lua/GTK interaction).
More importantly: the core framework just outright omits many of the core features that I've come to expect in tiling WMs. There's no support for i3-style window stacks, for example; I've tried several community solutions, but they're all trapped on a too-high abstraction layer and inevitably end up fighting with the WM in ways that you simply never need to deal with in first-class implementations.
All in all, I'm planning on returning to i3wm. For me, it's a bigger struggle to try building up a usable environment from scratch than it is to start with a solid foundation and then replace the undesirable components (i3bar => polybar, bindsym => sxhkd). AwesomeWM is very fun to work with thanks to the great APIs and documentation, but I can only wholeheartedly recommend it if you need absolute and total power over the UI, since that's AwesomeWMs whole schtick.
I've been using it for several years at this point and haven't encountered any memory leaks (it already uses so little).
As for widgets, I've had no trouble with that, there's quite a few fantastic collections and I've found everything I've needed.
Sure, stacks are not supported out of the box, but it is an easy thing to add if you want it. I think they are entirely consistent and bug free, as much as anything else - some specific apps might have an issue but you can also write a rule to deal with them as needed.
I'll take a completely customizable lightweight interface that I can tailor every aspect of every time, especially when it's so user friendly (for what it is).
> I've been using it for several years at this point and haven't encountered any memory leaks (it already uses so little).
It's the community widgets that tend to have memory leak problems, not the core package. As mentioned, this seems to be a quirk in how Lua and GTK interact (many community widgets use GTK).
> Sure, stacks are not supported out of the box, but it is an easy thing to add if you want it. I think they are entirely consistent and bug free, as much as anything else - some specific apps might have an issue but you can also write a rule to deal with them as needed.
They're not. I've used all of them. It's not an issue of rules, it's an issue of the core UI framework fighting against the hacked-on stacking implementation. There are design-time assumptions baked into the AwesomeWM layout engine that cannot be worked around using the API. You'll just have to take my word for it when I tell you that I've tried very hard and for a very long time.
> I'll take a completely customizable lightweight interface that I can tailor every aspect of every time, especially when it's so user friendly (for what it is).
I wouldn't really call AwesomeWM exceptionally user-friendly. The docs are good. The API is good. It's developer-friendly, certainly, but that's as far as the ease-of-use goes.
> It's the community widgets that tend to have memory leak problems, not the core package. As mentioned, this seems to be a quirk in how Lua and GTK interact (many community widgets use GTK).
What widgets are you referring to that you found to have leaks?
> You'll just have to take my word for it when I tell you that I've tried very hard and for a very long time.
It's just that it seems to contradict most of the other reports I've seen, but then I don't care about stacking myself, so ok.
> I wouldn't really call AwesomeWM exceptionally user-friendly. The docs are good. The API is good. It's developer-friendly, certainly, but that's as far as the ease-of-use goes.
I said it was user-friendly for what it is. There is nothing else really like it that allows that level of extensibility, and given how it abstracts so much complexity, I would say they did indeed do a good job of making it user friendly. Again though, that's keeping in mind what it is. It isn't trying to be i3/xfce/etc or as user-friendly as those.
I've had similar issues wherever GTK interacts with awful.spawn. Basically: glib (GTK) + awful.spawn.easy_async + polling = extremely leak-prone. This is a very common pattern in community awesomewm widgets.
Great idea! But how are you guys planning to pay for the APIs? I was playing around with it and one day just used up all my credits. I will share it with a friend of mine who provdies resume writing service
This is a side-project of ours for now. Actual costs have been minimal, save for our time - which we decided to cap just so we don't go into our usual perfectionism. So we haven't thought deeply about monetisation TBH.
If this ever gets _big_ - and hence useful to enough people - I would like to have a very simple and easy-to-appreciate monetisation. So not ads, nor subscriptions. Pay X and get 10*X value back in your life or somesuch thing.
Thanks for checking it out.
Right now we're trying to see if the product, in its very early stages, appeals to anyone. If they'll use it, come back to it, etc.
Then we'll most likely pay for the APIs. And think of monetisation and where we'd want to go with this.
That being said, are there any features you're keen on? anything you'd like to see that'll help you in your day to day?
This is pretty good. I can see a lot of people using the CV maker. I personally am not looking to create a resume/cover letter. But definite can see a job seeker use it. Have you guys considered an email correction addon powered by ChatGPT? These days I put rough drafts of the email I type into ChatGPT and ask it to rewrite it professionally.
