> (I originally was going to say a computer that plays chess, but computers play chess with no intuition or instinct--they just search a gigantic solution space very quickly.)
Isn't that how LLM models are trained right now? Trying to predict the next word within a "gigantic solution space". Interesting.
Which even shows Sam has no idea about AI, as the best chess engine at that point in time Komodo 8 was trained and developed primarily through the efforts of GM Larry Kaufman and Mark Lefler, focusing on refining the engine's evaluation function and search accuracy rather than relying on deep, brute-force calculation.
In one sense, all intelligence is a search in a gigantic solution space.
But the difference is:
What Deep Blue did was (if the Wikipedia page is correct) Alpha-beta pruning[0], where some humans came up with the function for what "better" and "worse" board states look like.
And what LLMs do (at least the end models) includes at least some steps where there's an AI trying to learn what human preferences are in the first place, in order to maximise the human evaluation scores. Some of those things are good, like "what's the right answer to the trolley problem?" and "which is the better poem?", but some are bad such as "what answer best flatters the ego of the user without any regard for truth?"
The former is exactly like route-finding, in that you could treat travel time as your score of better-worse and the moves as if they're on a map rather than a chess board.
The latter is like being dumped into a new video game with no UI and all NPCs interact with you only in a language you don't know such as North Sentinelese.
It's neither how computer chess works or how LLMs are trained.
Computer chess uses various tricks to prune the search space of board states, where the search is guided by the "value" of each board state. Neural networks can be used (and probably was at the time) to approximate this value, but there can be hand coded algorithms with learned statistics or even lookup tables for smaller games than chess.
In Germany we have several accounting software solutions like that for 5-10+ years that integrate with bank accounts, paypal, etc. - automatically suggests booking accounts and exports it via a REST API to the software accountants use. Accountants have access to it. Is this basically the same as your solution?
I will never use dark mode if I can avoid it. The idea that it's somehow better is a bit shady [0][1] (save for mobile devices where arguably it may help save some energy), but I absolutely understand that it can be a personal preference.
Well, we have to "register" every new IP or new mail server with them as well. It's annoying and a weird system, but they respond quickly and it's just one todo we have to think about.
What I am missing with Gnome is the global menu I have with macOS. It's just my preferred way of working. This is also what I liked about Unity. Gnome seems to follow the same direction as Windows.
Additionally miller columns in Finder are just awesome and I don't have them with Nautilus. Those two things are honestly dealbreakers for me.
I would much prefer if MacOS got rid of the global menu. I've contemplated it for literally decades, and my opinion has only gotten stronger.
1. Sometimes a program has no open windows. Understanding when its menu shows up in the menu bar is confusing at best. Explaining to another user "oh, you are in [such and such program already] even though there's nothing there -- click File then Open" is silly.
2. Sometimes a program has two or more open windows. Sure, File/New makes sense in this context, but anything that acts on the current window is not visually linked to the window and is thus confusing.
3. With the advent of multiple monitors, global menus are even worse. Which monitor should they live on? Always primary? Both? There is no right answer.
4. Old-fashioned title bars tell me which window belongs to which program. Global menus try, but only if I'm sure which window's menu is currently displayed, and it does not let me identify a non-selected window without interrupting myself to select it.
5. Opening a menu that's part of a non-current window takes one click. With global menus, it's two clicks.
6. One might imagine that they conserve screen real estate, which is maybe slightly true in our brave new world of notched viewports, but it's barely true and is avoidable. And Apple doesn't seem to care about efficient use of screen real estate anyway.
Personally, I think the trade offs for more window space is worth it versus window positioned app menu bars. If you really are trying to maximally optimize menu bar navigation you go with the menu bar as a context menu wherever your cursor is, or a key command to prompt searching for the menu option you want to use.
As for 3, the way you'd solve this while retaining the 'global' menubar style is by treating screens more individual and having a screen unique menubar. Introduce screen focus, and have the screen focus follow where the cursor is. Further you could make it so that when a screen regains cursor focus it also refocuses the last window on that screen. The menu bar would then serve the purpose of visually indicating and emphasizing which app on which screen has latent focus even when the screen lacks focus itself. (Which now saying it honestly might have been an original MacOS consideration before losing focus caused window dimming)
You don't have to like it, but the global menu bar is at the top of the screen which means you just fling the mouse to the top and then go left or right, instead of having to get to the right vertical.
True. This could be nicely solved by placing a non-global window all the way at the top of the window, so that you can still fling the cursor to the top of the screen if the window is maximized or otherwise along the top edge of the screen.
I had a longer reply but turfed it, but the global menu is based around muscle memory for eye and mouse locations. My personal experience sounds nothing like yours so I suspect we navigate very differently such that it impacts you far more than me.
I’m a heavy keyboard user so rotating apps and windows in apps means I always know where I am and don’t even notice the costs you’re talking about.
In Gnome, the top bar stays in the Primary monitor only, and worse, even the app switcher always displays on Primary monitor, NO MATTER which monitor you are in! Which is absolutely infuriating. I can't imagine how messy the Global menu could be in a multi monitor setup. Why would one want that pain!
I quite dislike the global menu of macOS. It means that you need to switch windows to see the menu for the window, which can result in a lot of tedious mouse movement.
But what I absolutely love is the menu search. I would love to see GNOME (well GTK I guess) add menu search. Also bring back the ability to bind hotkeys by typing while hovering a menu item while you are at it!
I went looking for a file manager with miller column on Linux once. It seems to be an extremely rare feature. With how popular column view is in Finder, I don’t understand how it hasn’t made its way to other platforms as a commonplace feature.
I had the exact same journey as you, I even very nearly install GNUStep because the file manager had miller columns.
I even started to think that perhaps Apple has an active patent on it or something.
(this happened with the Genie Lamp minimise effect on Compiz/Beryl- why it needed to have at minimum 3 "waves" before it minimised the window; though you could obviously patch it out).
FWIW I found Ranger (TUI) and Pantheon (ElementaryOS) that supports it, if you're still looking.
I like that Unity puts the global menu on the side. This makes more sense with all the wide-screens that we have nowadays. A huge oversight in MacOS, if you ask me.
On macOS only the dock can be moved to the side. The application menu (left) and the statusbar menu (right) will always be on top of the screen.
Which makes sense to me.
I agree that the side is better and would be a better default. For the record, the location of the MacOS Dock is configurable — I have mine on the right.
GitLab is very very heavy with a lot of bloat and sadly still a bad UI/UX. I prefer Gitea for its simplicity. Gitea Actions are similar to Github Actions and they work great.
The problem with ONCE is that software is never finished. This is why most ONCE software that is still available today is charging a one off licensing fee + update fee (e.g. charge yearly for major updates or 10% of the one off fee per year). This is sustainable, but your model isn't. You will notice down the road in 2-4 years that it's no fun to work for free for users that expect an update because it requires patching or there are breaking changes.
That’s a fair concern, but I see it differently. Software can reach a point of maturity - not “dead” just done. That’s the whole philosophy behind ONCE: build something great, maintain it responsibly, and stop when it’s complete.
Isn't that how LLM models are trained right now? Trying to predict the next word within a "gigantic solution space". Interesting.
reply