Yeah, ok, don't do it then. That doesn't mean because you do not want to bother, the suggestion is invalid for everyone here. There are a lot of people who just love to do their own thing, tinker with whatever they have on hand and then use the stuff they have created themselves.
Larger teams do not necessarily mean you get stuff faster. If anything after some point, a large team can be hard to get things moving and have tons of issues with communication.
AFAIK she also wrote the MPL, but the thing is, people change and doing good stuff 30 years ago doesn't mean they'd keep doing good stuff decades later.
In any case it doesn't really matter much anymore since apparently she left Mozilla around February.
An Nvidia GPU is the most common answer, but personally i've done all my LLM use locally using mainly Mistral Small 3.1/3.2-based models and llama.cpp with an AMD RX 7900 XTX GPU. It only gives you ~4.71 tokens per second, but that is fast enough for a lot of uses. For example last month or so i wrote a raytracer[0][1] in C with Devstral Small 1.0 (based on Mistral Small 3.1). It wasn't "vibe coding" as much as a "co-op" where i'd go back and forth a chat interface (koboldcpp) and i'd, e.g. ask the LLM to implement some feature, then i'd switch to the editor and start writing code using that feature while the LLM was generating it in the background. Or, more often, i'd fix bugs in the LLM's code :-P.
FWIW GPU aside, my PC isn't particularly new - it is a 5-6 year old PC that was the cheapest money could buy originally and became "decent" at the time i upgraded it ~5 years ago and i only added the GPU around Christmas as prices were dropping since AMD was about to release the new GPUs.
Yeah and it isn't just you accepting cash. Let's say you decide to go with cash (or, more realistically, manual bank transfers) and even get some host like 1984 that'd go to the court for you, but what stops Visa/MC to go directly at your host and tell them to either drop your site or they'll drop them?
In theory, if you went "full crypto", there's probably options like Filecoin and web3 domains (I'm not in that space enough to know what the current versions of these are) that could make something "uncensorable" by Visa/MC, but it also would limit its reach heavily.
Yes but Control isn't sold "just so the end user can enjoy exercising their new GPU and monitor", it is sold for gamers to play a great game. And IMO it is Remedy's best game since Max Payne 2 (i haven't played Alan Wake 2 though) because of its gameplay and atmosphere, not because of its visuals (which, do not get me wrong, are great, but that is largely because of the art direction and visual design, not because of raytracing -- in fact personally i first played and finished the game on an RX 5700 XT which has no raytracing at all and had to tone down a few visual effects, but still found the visuals great).
I don't really see your point. It was used by benchmarking youtubers for that benchmarking, so it at least sold to them for that reason. It's also the reason I bought it: any later enjoyment is unrelated.
> Development of Window Maker (as in the window manager) unfortunately seems to be almost abandoned. The last few years of it's development saw the inclusion of rather superfluous additional features (e.g., screen capture, hot corners) instead of concentrating on it's main purpose of being a window manager.
Hot corners is a great feature and it is in fact part of being a window manager since providing means to move and resize windows is one of the core aspects of window management.
> It's a pity no one ever tried to replace the WINGs widget set with actual GNUstep components
Uh, no, GNUstep is heavy, weird, doesn't look that good (all these smoothed out approximations of the NeXTSTEP look are ugly) and is incredibly buggy and unstable.
> thus adding the full GNUstep themeability WINGs is not capable of
I'd rather see WINGs adopt themes itself than use GNUstep.
> in order to finally get rid of that crufty NeXTSTEP look.
Some people actually like that NeXTSTEP look. In fact AFAIK historically Window Maker exists exactly because the original developer didn't like Afterstep not looking NeXTSTEP-like enough.
Yes, but there aren't any huge changes in it, so releases are sporadic. You can see that there is the occasional commit on git[0] though most patches posted in the developer's mailing list are for the dockapps (in a different repository), not WM itself.
I've been using (and contributed to) Window Maker for years - in fact it was my first non-DE window manager back in early 2000s. I have used other DEs (most notably GNOME 2 around mid-2000s) and WMs but when i use Linux i always end up back to Window Maker and it has been my main window manager for the last ~10 years as well as the only desktop environment i've been using since ~2021 or so.
Most applications work fine since there is little difference between WMs. That said there are two issues Window Maker has that nobody has fixed:
1. There is practically no RandR support. Sure, you can enable it (and i think it is enabled by default) during compilation but the "support" is really to restart Window Maker whenever the video mode or whatever else changes so that it uses the new resolution. However due to the way Window Maker seems to identify monitors (it seems to use the vertical resolution - probably a hack that worked for someone somewhere around the 90s or early 2000s and nobody bothered to update to use something less hacky) it also causes duplicate dock configurations. Also for some reason if the dock is larger than the vertical resolution anything that doesn't "fit" gets thrown away. Ultimately i've found it easier to just disable RandR support to avoid losing my dock configuration whenever some program changes the resolution.
2. While there is EWMH support, either there is some bug with how some parts are implemented or (most likely) there are subtle differences between Window Maker's implementation and other window managers (e.g. IceWM) that applications assumed would work like that cause issues with Window Maker. The most obvious of those is applications that want to "take over" window management and handle moving and resizing themselves - it either doesn't work (the applications do not move) or the move/resize happens erratically (e.g. Firefox with the titlebar disabled or Steam has this issue). Also many applications do not get the frame size (this is probably some race condition because Window Maker does set the frame size hints properly) correctly, causing them to get wrong sizes and when combined with them trying to handle sizing and position themselves, they can end up flickering by constantly trying to set the "correct" size and/or moving and sizing themselves whenever their UI updates (often becoming smaller and smaller because they assume some frame size of 0). This is most common with applications running under Wine, but some other applications have issues too because of that (e.g. Virtualbox).
I've tried to figure out the #2 (for #1 i just don't care that much since i'm using a single monitor anyway) but from what i could tell Window Maker seems to be doing everything properly. I didn't spent that much time on it though. At some point (and assuming nobody else does, though it has been like that for years) i'll try and compare what Window Maker does and what IceWM does (which works fine) and where their behavior differs. My guess is some race condition, perhaps Window Maker sets the hints too late or something, though this is just a guess. I'll need first to write a small X11 program that replicates the issue.
As a workaround for #2 i've been using a feature i added to Window Maker years ago to ignore any decoration changes for windows (it is in Attributes -> Advanced Options -> Ignore decoration changes), essentially forcing all windows to have a resize frame and titlebar, ignoring any requests for hiding them. This lets me move around and resize, e.g., Steam (and also use all window management functionality that Window Maker provides - like rolling the window up/down using the mouse wheel - instead of whatever Valve thought i'd need).
One other issue with Window Maker (though it isn't really a Window Maker issue per-se) is that since Window Maker is not a (desktop) compositor, Gtk4 applications that assume a compositor will use black colors for whatever would be beneath a window - this mainly means that popup menus with rounded corners will actually get black corners. This is really a side-effect of Gtk4 assuming a compositor is there and not having a fallback for when there isn't one and would be an issue with other window managers too, but it should be solvable (if you care about it, i don't) by using a dedicated compositor (i think compiz or something like that may work).
I'm still using wmaker starting from late 90s (also had couple minor contributions)
> 1. There is practically no RandR support.
It is awkwardly implemented yes, as internally wmaker will restart, although changing resolution works for me most of the time. Wmaker doesn't identify monitors, it talk with xlib to get the layout when new display is detected or removed.
As for double dock - never have double dock issue. Sometimes I ended up with lossing it's configuration, especially in a cases when resolution set for the display is too low. That might happen when no display is detected/connected, then resolution is set to 64x64 pixels by X.
> 2. While there is EWMH support, […]
It's partially implemented, and indeed it lacks of handling self-managed application. Some apps are working fine (AFAIRC GTK3 based) and some don't (steam client), but in general for those which are not cooperate modifier key can be used to move such window around and keyboard shortcuts (which I'm mostly using anyway) to resize. Or to force window to use wmaker decorations as you mentioned.
This issue I've tried to solve couple of years ago[1], found culprit, but I've failed to do so. I've also spend a large chunk of time to compare it with PekWM, where those things are working as intended, but stuck on event handling.
As for composition. You might consider to use standalone one (xcompmgr, compton, picom, etc) just to get the effects.
> Wmaker doesn't identify monitors, it talk with xlib to get the layout when new display is detected or removed.
It'll restart if anything changes, but the problem is...
> As for double dock - never have double dock issue. Sometimes I ended up with lossing it's configuration, especially in a cases when resolution set for the display is too low.
...that it attempts to create different dock configurations based on the monitor height (you can see that if you check the configuration file). This is something that would make some sense in a pre-Xinerama world where Window Maker would be launched for each monitor, but it doesn't make some sense post 2000s and is really just some ancient hack that nobody bothered to fix.
> It's partially implemented, and indeed it lacks of handling self-managed application.
AFAICT the support is there, but some applications seem to assume some additional de-facto behavior that Window Maker does not have. Initially i also assumed the support wasn't there and i went into implementing it myself, only to find out that it is already implemented - and seemingly works as the spec describes.
> ...that it attempts to create different dock configurations based on the monitor
it will create dock based on the new display IF the new display is the primary one. You can have displays in different resolution, and it will work. I'm using dual monitor on daily basis and occasionally connect additional one, and didn't get "dual dock" for years. Let me stress it again - dock conf will get messed up, if resolution for the display is smaller then current dock height.
> I'm using dual monitor on daily basis and occasionally connect additional one, and didn't get "dual dock" for years.
I think there was a misunderstanding here, i wrote "duplicate the dock configuration", not that there was a "dual dock" on screen. Basically if you open `WMState`, under the `Dock` node you'll see something like `Applications { ... }` but also an `Applications<height> { ... }`.
The reason being that Window Maker uses the current screen height to identify which dock to load/save by attempting to load `Applications<height>` and if there isn't such an entry (it doesn't try other heights), it reverts to `Applications`, if any or just destroys the dock.
This behavior (which has been here since 1999[0]) combined with restarting whenever RandR restarts means you get to lose your dock setups whenever the resolution changes. Or if you want to be more generous, you get to use a different dock per resolution.
Which is why i do not have RandR compiled it.
> Nope [1]. Not for those message types.
Yeah, sorry, i meant _NET_FRAME_EXTENTS for calculating frame size, which causes issues with Wine and some other applications.
> I think there was a misunderstanding here, i wrote "duplicate the dock
Oh, right. For me it will always be messed up dock conf, when resolution of the screen, where dock resides, will be lesser than actual dock height. I guess that thing deserve a bug report. I bet most of users would expect to have dockapps preserved even if those are out of reach because of screen size.
> Yeah, sorry, i meant _NET_FRAME_EXTENTS for calculating frame size,
That's true.
FWIW even with those annoyances, wmaker is still usable. The only things which manifests to me are virtualbox trying to fight wmaker in window placement and steam launcher which lacks of ability to move around with mouse (without modifier key).
TBH, I'm pretty happy with it, perhaps my workflow plays a role here, as I'm rather keyboard person, and mouse is used mostly on web browser.
> bad the Linux project is at changing their ABI and how good OpenBSD is at the same task
From my perspective as a user who wants to have his programs keep working whenever the OS updates and as a programmer who does not want to waste their time playing nanny with broken dependency upgrades for previously working code (working in the sense that it did what it was supposed to do), the Linux project is actually doing the thing the right way and OpenBSD the bad way. It is basically the #1 reason i never considered using OpenBSD.
Linux' stance on not breaking backwards compatibility is exactly what i want from an OS. Now if only the userspace libraries weren't so happy to break things too...
reply