Python Is All You'll Ever Need In This Linux Distro

Choosing the perfect Linux distribution that satisfies your personal needs and likings can be an impossible task, and oftentimes requires a hint of Stockholm syndrome as compromise. In extreme cases, you might end up just rolling your own distro. But while frustration is always a great incentive for change, for [Josh Moore] it was rather curiosity and playful interest that led him to create snakeware, a Linux distribution where the entire user space not only runs on Python, but is Python. Imagine you would boot your Linux system, and instead of the shell of your choice, you would be greeted by an interactive Python interpreter, and everything you do on the system will be within the realms of that interpreter — that’s the gist of snakeware. Now, this might sound rather limiting at first, but keep in mind we’re talking about Python here, a language known for its versatility, with an abundance of packages that get things done quick and easy, which is exactly what [Josh] is aiming for. To get an idea of that, snakeware also includes snakewm, a graphical user interface written with pygame that bundles a couple of simple applications as demonstration, including a terminal to execute Python one-liners.

Android Leftovers

• Users discover wallpaper that can crash some Android phones

• Google Postpones Android Reveal, "Now is Not the Time to Celebrate"

• Google Postpones Android 11 ‘Beta Launch Show’ Amid Protests

• Nokia 9 PureView gets new Android 10 build, Nokia 3.1 Plus and Nokia 1 May 2020 security patch

• Lilbits 6-01-2020: Android 11 beta leaked early, postmarketOS turns 3, and a new PC stick

• Today’s best Android game/app deals + freebies: Prune, Star Traders, more

• TDS begins rollout of new Android TV-based video service

• Is Zoom the next Android or the next BlackBerry?

Torvalds Blasts "Beyond Stupid" Flushing L1d On Context Switches - Reverts Code For Now

As part of the initial set of changes merged today for Linux 5.8 was the x86/mm material that included the controversial feature of opt-in flushing of the L1 data cache on context switching. Linus Torvalds ended up deciding to revert this functionality as for now at least he views it as crazy. While this feature is opt-in via new prctl options and not enabled by default and done in the name of helping those concerned about snoop assisted data sampling vulnerabilities or cache leakage via side channels and yet to be uncovered CPU vulnerabilities, for the time being Linux creator Linus Torvalds is not convinced. Original:

• Re: [GIT PULL] x86/mm changes for v5.8

  >  - Provide an opt-in (prctl driven) mechanism to flush the L1D cache on context switch.
  >    The goal is to allow tasks that are paranoid due to the recent snoop assisted data
  >    sampling vulnerabilites, to flush their L1D on being switched out.
  
  Am I mis-reading this?
  
  Because it looks to me like this basically exports cache flushing
  instructions to user space, and gives processes a way to just say
  "slow down anybody else I schedule with too".
  
  I don't see a way for a system admin to say "this is stupid, don't do it".
  
  In other words, from what I can tell, this takes the crazy "Intel
  ships buggy CPU's and it causes problems for virtualization" code
  (which I didn't much care about), and turns it into "anybody can opt
  in to this disease, and now it affects even people and CPU's that
  don't need it and configurations where it's completely pointless".
  
  To make matters worse, it has that SW flushing fallback that isn't
  even architectural from what I remember of the last time it was
  discussed, but most certainly will waste a lot of time going through
  the motions that may or may not flush the L1D after all.
  
  I don't want some application to go "Oh, I'm _soo_ special and pretty
  and such a delicate flower, that I want to flush the L1D on every task
  switch, regardless of what CPU I am on, and regardless of whether
  there are errata or not".
  
  Because that app isn't just slowing down itself, it's slowing down others too.
  
  I have a hard time following whether this might all end up being
  predicated on the STIBP static branch conditionals and might thus at
  least be limited only to CPU's that have the problem in the first
  place.
  
  But I ended up unpulling it because I can't figure that out, and the
  explanations in the commits don't clarify (and do imply that it's
  regardless of any other errata, since it's for "undiscovered future
  errata").
  
  Because I don't want a random "I can make the kernel do stupid things"
  flag for people to opt into. I think it needs a double opt-in.
  
  At a _minimum_, SMT being enabled should disable this kind of crazy
  pseudo-security entirely, since it is completely pointless in that
  situation. Scheduling simply isn't a synchronization point with SMT
  on, so saying "sure, I'll flush the L1 at context switch" is beyond
  stupid.
  
  I do not want the kernel to do things that seem to be "beyond stupid".
  
  Because I really think this is just PR and pseudo-security, and I
  think there's a real cost in making people think "oh, I'm so special
  that I should enable this".
  
  I'm more than happy to be educated on why I'm wrong, but for now I'm
  unpulling it for lack of data.
  
  Maybe it never happens on SMT because of all those subtle static
  branch rules, but I'd really like to that to be explained.
  
                      Linus