First full day running @buddiesofbudgie #Budgie Desktop on top of a Wayland compositor. Even in it's still very heavily WIP form.
Panel exclusion zone now implemented and thanks to some rubber ducking / help from @EbonJaeger , figured out what was wrong with my Budgie PopoverRedux.
Old Budgie.Popover code is gone, all the popovers are using the new implementation which are basically just Gtk.Popover. It'll be renamed back to Budgie.Popover once I do cleanup of PopoverManager and maybe refactor some more code.
Screenshot shows the bluetooth applet... well now being shown, as well as VS Code not being allowed to be maximized under the panel.
Biggest usability thing next for me will be making Raven not 100% full screen and the panel to always be set to the primary monitor rather than whichever monitor is in focus.
In math research papers (particularly the "good" ones) one often observes a negative correlation between the conceptual difficulty of a component of an argument, and its technical difficulty: the parts that are conceptually routine or straightforward may take many pages of technical computation, whereas the parts that are conceptually interesting (and novel) are actually relatively brief, once all the more routine auxiliary steps (e.g., treatment of various lower order error terms) are stripped away.
I theorize that this is an instance of Berkson's paradox. I found the enclosed graphic from https://brilliant.org/wiki/berksons-paradox to be a good illustration of this paradox. In this (oversimplified) example, a negative correlation is seen between SAT scores and GPA in students admitted to a typical university, even though a positive correlation exists in the broader population, because students with too low of a combined SAT and GPA will get rejected from the university, whilst students with too high a score would typically go to a more prestigious school.
Similarly, mathematicians tend to write their best papers where the combined conceptual and technical difficulty of the steps of the argument is close to the upper bound of what they can handle. So steps that are both conceptually and technically easy don't occupy much space in the paper, whereas steps that are both conceptually and technically hard would not have been discovered by the mathematician in the first place. This creates the aforementioned negative correlation.
Often the key to reading a lengthy paper is to first filter out all the technically complicated steps and identify the (often much shorter) conceptual core.
@mashiro 站长,小森林(网页版)有这个功能吗?没找到
I'd like to remind all Mastodon users that you can add a language filter to any follow relationship on Mastodon.
If you follow me and you don't speak German, you can easily remove my German posts from your timeline by adjusting the language settings.
Go to my profile page, select the dot menu and click "Change subscribed languages". Then select the languages that you speak.
This really is a hidden gem 💎 on Mastodon and not many people seem to know this feature
WARNING! This image may trigger PINSecurity.
From an analysis of 3.4m PIN code leaked from several data breaches https://informationisbeautiful.net/visualizations/most-common-pin-codes/
[Well-Typed Blog] Improvements to the ghc-debug terminal interface
`ghc-debug` is a debugging tool for performing precise heap analysis of Haskell programs (check out [our previous post introducing it](https://www.well-typed.com/blog/2021/01/fragmentation-deeper-look/)). While working on [Eras Profiling](https://www.well-typed.com/blog/2024/01/ghc-eras-profiling/), we took the opportunity to... #haskell
https://www.well-typed.com/blog/2024/04/ghc-debug-improvements/
“When drivers fail to yield for pedestrians, it’s not because they can’t see them, it’s because they don’t care.” Kudos to @VisionZeroYVR for this brilliant intervention. https://momentummag.com/vision-zero-campaign-bricks-vancouver/ #TheWarOnCars
Do you want to stop "supply chain compromises" as a company? Here's a very simple way to do so: pay a stipend to a maintainer of something you depend on.
You don't really need dependency tracking tools. You don't need to exactly parcel out the 'right' proportionate amount of money to every maintainer. All of that operational complexity is unnecessary.
It doesn't even matter *which* maintainer you pick, as long as it's one who isn't receiving a stipend yet, and you pay them enough to constitute a salary.
It will cost you exactly one developer salary. If every able company does this, the problem of supply chain compromises is solved tomorrow.
All you need to do is simply *do it*, and talk about it so that other companies will too.
history = (λx. x x) (λx. x x)
When life gives you lemons, don't make lemonade. Make life take the lemons back! Get mad! I don't want your damn lemons, what the heck am I supposed to do with these?