Games: Newer Windows Games On Wine, Steam on Chrome OS and Soldat's Source Code

• A New Kernel Patch Is Being Discussed That's Needed For Newer Windows Games On Wine

  Newer Windows games/applications are making use of system call instructions from the application code without resorting to the WinAPI and that is breaking Wine emulation support. A Linux kernel patch is now being worked on for addressing this issue in the form of system call isolation based on memory areas while having a smaller performance hit than alternatives. With newer Windows software executing system call instructions without going through the Windows API, Wine isn't able to intercept and emulate those system calls and thus breaking the support. Wine can't really rework its handling of every system call as that would thrash the performance. So a Linux kernel-based solution is being sorted out.

• Cloud FTW: Steam on Chrome OS may not look like we thought

  Back in January, word got out that Google and Valve were collaborating to bring some form of native Steam client to Chrome OS. Director of Product Management Kan Liu told Android Police that the project would leverage Crostini, aka Linux on Chrome OS. Because I spend a good portion of my days tinkering with Linux on my Chromebook, I hastily presumed that Steam would be delivered in some sort of Chrome OS-optimized Linux package. While that could still be a possibility, it appears that Valve may look to the Clouds in Steam’s next evolution.

• Soldat source code released and a story of how it all started

KDE Development: Adriaan de Groot and New GSoC Students

• Timezones, yes please

  One of the bits of Calamares that I think is most terrible is the timezone selector. So I was very happy to read Volker’s ideas about timezone-mapping. Calamares is a universal Linux installer, used by some dozens of Linux distro’s. It is built as a framework, customizable by downstreams to their liking. This is basically a service to the small-distro Linux community, and PRs are very welcome .. but I digress. Part of installation is picking a timezone to put the system in. Calamares offers a map, and you click on it, and it picks a likely location, and off you go. The technology used is simple: there’s a PNG for each timezone (this sounds familiar). The user clicks on the PNG of the world map, and the mouse coordinates are mapped to a location (longitude and latitude), the location is mapped to a zone offset that gets mapped to a timezone image, and the image is drawn.

• The Community Bonding Period Ends

  It has been almost a month, since the commencement of community bonding period and the phase was mostly good. I spent most of my time lurking over the IRC in passive reconnaissance mode, force of habit I mostly speak less and I know it is not a good one especially being part of an open-source community. I used to attend all the meetings and tried to get accustomed with the workflow of the community and got to know about everything hot and spicy that is taking place whether it is Krita finally on android or new contributors working on some bugs.

• KDE Conference India 2020: A very late post

  KDE India Conference 2020 was successfully organized in Maharaja Agrasen Institute of Technology. It was a three-day event, from Jan 17 to Jan 19. There were talks about Libre, Open Source Software and how software is developed using C++ and the Qt Framework. Hands-on workshops were also organized on C++, Qt and QML which gave attendees a good start on how to start their journey with C++ and Qt Framework. The conference was able to educate 200+ attendees throughout the conference. Refreshments were provided to all present for the conference on all 3 days. Every day of the conference concluded with dinner at various good places in Delhi with all the speakers, organizers and volunteers.

• About me, who am I?

  I am Shubham, a final year undergraduate student, pursuing B.E(Bachelor of Engineering) at BMS Institute of Technology and Management, Bangalore, India. I am an open source enthusiast and developer, mostly working with C++ with Qt framework. I also have decent knowledge of C, Java, Python, bash scripting, git and I love developing under linux environment. Previously I was selected as one of many GSoC students to be mentored by this amazing organization, which is KDE. This year also, I applied again to KDE as a student and was fortunate enough to get selected. I will be developing for Cantor project. Apart from coding, in my spare time I go for Cricket or Volleyball to keep myself refreshed.

• Integrated Documentation in Cantor

  Cantor is an application that lets user use their favourite mathematicalapplications from within a nicely KDE-integrated worksheet interface. It offers assistant dialogs for common tasks and allows users to share their worksheets withothers. Cantor is one of many KDE educational projects. It supports a variety of backends, be it Maxima, Octave, Python, R and many more and that too packed in a single intuitive GUI. The current version of Cantor does not have support for viewing backend's documentation inside the application itself. For example, to view Maxima’s documentation or help, the application provides an external link pointing to the Maxima’s official documentation page which is opened in a fresh browser window. This has the obvious drawback of requiring an active internet connectivity.

The Linux Kernel Deprecates The 80 Character Line Coding Style

The Linux kernel has officially deprecated its coding style that the length of lines of code comply with 80 columns as the "strong preferred limit". The Linux kernel like many long-standing open-source projects has a coding style guideline that lines of code be 80 columns or less, but now that while still recommended is no longer going to be as enforced. This stems from Linus Torvalds commenting on Friday that excessive linebreaks are bad and is against ugly wrapped code that is strictly sticking to 80 characters per line. This is part of the broader trend that most are no longer using 80x25 terminals but with today's high resolution displays the terminal sizes are often larger though some preferring the default in order to allow more terminals to be displayed simultaneously on their nice displays. Original from Torvalds:

• clean up kernel_{read,write} & friends v2

  Not necessarily.
  
  Excessive line breaks are BAD. They cause real and every-day problems.
  
  They cause problems for things like "grep" both in the patterns and in
  the output, since grep (and a lot of other very basic unix utilities)
  is fundamentally line-based.
  
  So the fact is, many of us have long long since skipped the whole
  "80-column terminal" model, for the same reason that we have many more
  lines than 25 lines visible at a time.
  
  And honestly, I don't want to see patches that make the kernel reading
  experience worse for me and likely for the vast majority of people,
  based on the argument that some odd people have small terminal
  windows.
  
  If you or Christoph have 80 character lines, you'll get possibly ugly
  wrapped output. Tough. That's _your_ choice. Your hardware limitations
  shouldn't be a pain for the rest of us.
  
  Longer lines are fundamentally useful. My monitor is not only a lot
  wider than it is tall, my fonts are universally narrower than they are
  tall. Long lines are natural.
  
  When I tile my terminal windows on my display, I can have 6 terminals
  visible at one time, and that's because I have them three wide. And I
  could still fit 80% of a fourth one side-by-side.
  
  And guess what? That's with my default "100x50" terminal window (go to
  your gnome terminal settings, you'll find that the 80x25 thing is just
  an initial default that you can change), not with some 80x25 one. And
  that's with a font that has anti-aliasing and isn't some pixelated
  mess.
  
  And most of my terminals actually end up being dragged wider and
  taller than that. I checked, and my main one is 142x76 characters
  right now, because it turns out that wider (and taller) terminals are
  useful not just for source code.
  
  Have you looked at "ps ax" output lately? Or used "top"? Or done "git
  diff --stat" or any number of things where it turns out that 80x25 is
  really really limiting, and is simply NO LONGER RELEVANT to most of
  us.
  
  So no. I do not care about somebody with a 80x25 terminal window
  getting line wrapping.
  
  For exactly the same reason I find it completely irrelevant if
  somebody says that their kernel compile takes 10 hours because they
  are doing kernel development on a Raspberry PI with 4GB of RAM.
  
  People with restrictive hardware shouldn't make it more inconvenient
  for people who have better resources. Yes, we'll accommodate things to
  within reasonable limits. But no, 80-column terminals in 2020 isn't
  "reasonable" any more as far as I'm concerned. People commonly used
  132-column terminals even back in the 80's, for chrissake, don't try
  to make 80 columns some immovable standard.
  
  If you choose to use a 80-column terminal, you can live with the line
  wrapping. It's just that simple.
  
  And longer lines are simply useful. Part of that is that we aren't
  programming in the 80's any more, and our source code is fundamentally
  wider as a result.
  
  Yes, local iteration variables are still called 'i', because more
  context just isn't helpful for some anonymous counter. Being concise
  is still a good thing, and overly verbose names are not inherently
  better.
  
  But still - it's entirely reasonable to have variable names that are
  10-15 characters and it makes the code more legible. Writing things
  out instead of using abbreviations etc.
  
  And yes, we do use wide tabs, because that makes indentation something
  you can visually see in the structure at a glance and on a
  whole-function basis, rather than something you have to try to
  visually "line up" things for or count spaces.
  
  So we have lots of fairly fundamental issues that fairly easily make
  for longer lines in many circumstances.
  
  And yes, we do line breaks at some point. But there really isn't any
  reason to make that point be 80 columns any more.
  
                    Linus