This is not a window manager, so thanks for stating the obvious. You might not like wayland and that's fine with me, but if you decide to hate on it, you should at least know what you are hating on. There are good reasons to prefer a wayland compositor over X11. If you don't care about these reasons, that doesn't mean nobody should.
My attempt at a definition of a desktop shell would be:
The collection of all the software that aids a compositor (or a window manager on X11) in providing a more complete desktop experience.
Now that's kind of vague and probably also not quite correct, so a more concrete explanation would be: A program or collection of programs that gives you desktop notifications, a taskbar (with a system tray), volume controls and more stuff like that, maybe even a neat menu to configure most of this. Usually for standalone compositors/window managers you'd usually use a collection of tools like dunst, polybar, and the like, but with newer tools like quickshell, which was used here, it's reasonably easy to build a single tool which handles most of that. And that's what we're looking at here ^^
Yeah, yay works until it doesn't anymore, because the pacman library dependency it uses was updated but yay was not... and then you need to recompile yay manually. I mean, I'll still use it (or rather paru, which works basically the same way), but it's very annoying, when it happens every few months.
That's assuming you do system upgrades through paru/yay. However, you may not want to upgrade the packages you've obtained from the AUR and so you upgrade using pacman. That may cause the updated libalpm to become incompatible with the installed yay/paru.
Iirc it was to force the extra step necessary for the user to acknowledge that the AUR can bootstrap malware if used blindly.
This seems to be a relatively consistent discussion surrounding AUR helper development; for example, adding UX to incentivise users to read PKGBUILDs, lest the AUR becomes an attractive vector for skids.
No one wants the AUR to become NPM, and the thing that will incentivise that is uneducated users. Having the small barrier of not having helpers in the main repos is an effective way of accomplishing that.
Assume they mean having to recompile the AUR package they were trying to install using yay.
If users mental model is mostly "yay is like pacman but can also install packages from AUR the same way" wihout thinking deeper about the difference then I think it using it is very risky and that you should just stick to pacman + git/makepkg. Only consider helpers once that's become second nature and routine. Telling people to "just yay install" is doing them a disservice. An upgrade breaking the system isn't even that bad compared to getting infected with malware due to an old package you were using being orphaned and hijacked to spread malware or getting a bad copycat version due to a typo.
I think EndeavourOS is doing users a disservice if they provide sth like yay preinstalled and ready to use out of the box. It isn't installing packages from a shared repo: It's downloading code from arbitrary locations and running it on your machine in order to produce a package. Being able to read and understand shell script (PKGBUILD) is kind of a prerequisite to using it safely.
That's a fair point. Model prices can increase. This raises the next question.
Doesn't this mean that any company that depends on headcount growth (every SaaS), loses?
100 SWE -> 10 SWE, 100 slack/gmail/notion/zoom/etc. subscriptions become 10.
And now let's recurse.
These SaaS companies that use AI and dropped 90% of engineering headcount lose revenue because their customers also drop headcount.
Let's say AI costs 89% more than it did before, so the SaaS companies still get 10x productivity from the 10 engineers, but now all their customers headcount is 90% smaller too. So what now? Does every company make a pact to grow headcount ;)
Yeah post 3.10 you don't need Union, Optional, List, Duct, Tuple. Any still necessary when you want to be permissive, and I'm still hoping for an Unknown someday...
By default, Mypy warns you if try to reassign a method of any object[1]. It will also warn you when you access non-existent attributes[2]. So if you have a variable typed as `object`, the only attributes you can manipulate without the type checker nagging are `__doc__`, `__dict__`, `__module__`, and `__annotations__`. Since there are very few reasons to ever reassign or manipulate these attributes on an instance, I think the `object` type gets us pretty darn close to an "unknown" type in practice.
There was a proposal[3] for an unknown type in the Python typing repository, but it was rejected on the grounds that `object` is close enough.
In my opinion the sheer volume of "close enough" choices is what ruins Python's type system.
It's "close enough" to a usable type system that it's worth using, but it's full of so many edge cases and so many situations where they decided that it would be easier if they forced programmers to try and make reality match the type system rather than the type system match reality.
No wonder a lot of people in the comments here say they don't use it...
I think they can get away with the "close enough" solutions since Python's type annotations don't have any runtime contracts by default. Might be off-putting to people who are more familiar with statically typed languages (though not always, in my experience).
I would buy that argument more if Typescript didn't exist.
You can live with the "close enough" if you're writing a brand new greenfield project and you prevent anyone from ever checking in code mypy doesn't like and also don't use any libraries that mypy doesn't like (and also don't make web requests to APIs that return dictionary data that mypy doesn't like)
Retrofitting an existing project however is like eating glass.
I am glad they improved this but I still like Optional[], and to a lesser extent, Union[]. It's much more readable to have Optional[str] compared to str | None.
I disagree with `Optional`. It can cause confusion in function signatures, since an argument typed as "optional" might still be required if there is no default value. Basically I think the name is bad, it should be `Nullable` or something.
I believe Python's own documentation also recommends the shorthand syntax over `Union`. Linters like Pylint and Ruff also warn if you use the imported `Union`/`Optional` types. The latter even auto-fixes it for you by switching to the shorthand syntax.
Could be, I've seen a weird trend of using AI to write content when it doesn't make sense. Sure, using it to write a blog post about a topic is "slop" but I can see arguments for it. Using it to improve thoughts you have in your head, by making up details and add emojis however, I can't understand.
For example as a heavy FB Market place user I see a lot of stuff like:
[picture of an iPhone 12]
- iphone 14
- new battery
- delivers to [enter your state here]
- comes with [enter accessories it comes with]
Like they were too lazy to even fill in the brackets or ensure some level of accuracy. What's the point?
That's a problem that was solved in the 1980s with the introduction of "mail merge" functionality in word processors. Using an LLM to do this is like using a sledgehammer to swat a fly.
