- Wayland is a significant improvement in one specific area (and it's not this one).
All programs in X were trusted and had access to the same drawing space. This meant that one program could see what another one was drawing. Effectively this meant that any compromised program could see your whole screen if you were using X.
Wayland has a different architecture where programs only have access to the resources to draw their own stuff, and then a separate compositor joins all the results together.
Wayland does nothing about the REST of the application permission model - ability to access files, send network requests etc. For that you need more sandboxing e.g. Flatpak, Containers, VMs
- I think this article is missing the point a bit.
It's saying that the action of calling an async function (e.g. one you've written) isn't itself a yield point. The only yield points are places where we the call would block for external events like IO or time - `await asyncio.sleep(100)` would be one of those.
This is true, but surely fairly irrelevant? Any async function call has somewhere in its possible call tree one of those yield points. If it didn't then it wouldn't need to be marked async.
- There's all sorts of things you can do if you don't care about money.
The more interesting point is that if you aren't driven by investors to care about short term financial stuff (stock prices) then you can make long term decisions. Caring about your customers is a classic one for this - costs you money in the short term, but in the long term gets you a great customer base.
- If you buy a Steam Deck and just use it as a handheld console and never select "reboot to desktop mode" it will act just like a closed console. The exceptions compared to something like a Switch:
- For some games (usually those oriented around keyboard and mouse) you need to go and select one of the community control configurations, and maybe tweak it a bit. For example, I needed to do this with FTL to make it easily playable
- Occasionally (and I've basically had to do this once, in my 2+ years with a Steam Deck) you need to go and select a different Proton version to make it work. ProtonDB tells you what to do
This is all rare though. The vast majority of games have a control setup for using a controller, and they definitely do if they've ever been released on console. And they will Just Work.
- There's a circular opportunity though - if the SteamOS market share gets anywhere, then it might become worth it for these developers to support anti-cheat on the that platform. Some systems (notably BattleEye) actually have Linux support, they just need to enable it, but there's no incentive for them to do so.
- When talking about Elixir (or Erlang) you are actually talking about two things that give you the value:
- A language (Elixir/Erlang) and runtime (BEAM) - The concurrency standard library (OTP)
The language and runtime give you the low level concurrency primitives - spawn a process, send a message etc. But to build actual applications, you rarely use those primitives directly - instead you use GenServers and supervisors. That gives yo a way to manage state, turns message passing into function calls, restarts things when they crash etc.
Gleam compiles to the same runtime, but doesn't provide OTP in the same way - static types aren't easy to make work with the freely message passing world of OTP. They are implementing a lot of the same concepts, but that's work that Gleam has to do.
(Elixir provides some thin API wrappers over the Erlang OTP APIs, and then also provides some additional capabilities like Tasks).
- Oban is great, but for most cases you don't need it. In languages with a less good concurrency model we are used to needing some form of library or system to manage "background jobs", but in Elixir you can just spin up some GenServers under a supervisor to do work. Start there and only use Oban if there's some form of consistency/resumability guarantee that you need.
- > Trains are all very well but they've been around nearly 200 years and have yet to bring on a traffic free utopia.
Cars will always have a purpose. But if you go to somewhere like The Netherlands, they are much less relied upon - it's more about delivery vans than getting individuals to places.
- > MCU-class footprint (fits in 16 MB RAM)
That is absolutely not an MCU class footprint. Anything with an "M" when talking about memory isn't really an MCU. For evidence I cite the ST page on all their micros: https://www.st.com/en/microcontrollers-microprocessors/stm32...
Only the very very high performance ones are >1MB of RAM.
- Did you miss:
> numpad input module
You can literally add a physical numpad if you want: https://frame.work/gb/en/products/16-numpad?v=FRAKDM0001
- Shipping binary artifacts isn't inherently a bad thing - that's what (most) Linux Distros do after all! The important distinction is how that binary package was arrived at. If it's a mystery and the source isn't available then that's bad. If it's all in the open source repo and part of the Python package build and is completely reproducible then that's great.
- It is true that the Swiss have more money to spend on rail, but this makes a compelling case that we aren't spending our money as effectively.
A lot of people have spent a lot of time (accurately) pointing out how badly HS2 has gone and why. Very few people have pointed out a viable and concrete alternative.
- It's not a commit per change - all changes made since the last commit are in a new commit. You then usually do one of two things:
- Decide your changes are perfect, so add a commit message to this one and then create a new one on to to carry on
- Decide you only want some of them so use `jj split -i` to select which ones you want and then it creates two commits - the stuff you want in a new named commit, and the stuff you didn't in a new working copy commit. This is the JJ workflow equivalent to `git add -p` adding to the staging area then committing
- Two reasons:
I don't use a tiling WM, and tmux[1] does an excellent job at the tiling features.
I do the majority of my work physically at a Linux (Fedora) desktop, but I also work from home SSH'd to that desktop. Being able to just attach to the same session and pick up where I left off, with all the same shell management, is great.
[1] I used tmux for years, but have very recently switched to Zellij. I find the pane navigation to be much smoother (and more discoverable).
- > US sports tend to have less meaningful "regular" seasons, which just seed "play-offs", which themselves often have "Best of X series".
Except if you look at the NFL - the most popular sport in the US by far - the playoffs are "Best of 1". The NFL also enforces very close parity which gives a lot of unpredictability. You combine those and you get a lot of upsets.
- I think there is a "best" p-value, and I don't think it's the "highest" p-value.
You don't want it too low, because then quality becomes meaningless. You do want to give good results to good teams. But there is also don't want it to be perfect - you want some unpredictability in sports. You don't want every match to be a foregone conclusion, and you want every supporter to be able to have some reasonable hope.
There is some data suggesting that one of the reasons that English football is popular is because it's low scoring. This increases the chance that random variation gives an "incorrect" result. In this hypothesis, unpredictability adds excitement and builds popularity.
The NFL achieves similar results a different way - various forms of consistency and negative feedback (salary cap, draft order, schedule) to keep teams very close in ability. This means that small differences like a game plan for a particular week can regularly affect results, and keeps predictability low.
- In a similar vein, we used "Kinder", which is like Tinder except it's for choosing baby names - it shows you names that both you and your partner swiped right on.
https://apps.apple.com/us/app/kinder-find-baby-names/id10684...
Imagine the other way - you have peopel dong a role, and the people who do the best job at that role get promoted to the next one. Some of them will be good and the new role, some of them won't. The ones who are good will carry on getting promoted. The ones who aren't will get stuck in that role. The problem is that everyone rises to a point at which they can't do the job, and every role is filled by someone who has been promoted one step too far.
In a healthy structure, it should be a halfway house - you shouldn't have to be doing the whole job that you're trying to get promoted to, you should be doing enough bits and pieces of it that you demonstrate that you CAN do it. That way the company has information that they're not promoting you to a position of incompetence.