Language Selection

English French German Italian Portuguese Spanish

Top 10 Best Linux Laptops Out Right Now

Filed under
GNU
Linux

Linux has a cult following and for good reason. From powerful functionality to robust services, it is hard to beat a Linux laptop when it comes to day-in, day-out use. Preferred by everyone from programmers to hacking communities, Linux laptops are some of the best hardware out there for someone just learning to code or who has done it for years. They’re just a superior option to a Windows or Mac machine in many, many ways.

But you already know that, right? That’s why you’re here to find out about the best Linux laptops out on the market right now. And we’ve got you covered. In this article we will discuss the 10 best Linux laptops currently available on the market and why you should consider adding them to your arsenal. There’s a device at every price point and budget consideration so you should be able to find something that hits that sweet spot for you.

Read more

Also: Crostini Linux Headed To Older Broadwell Chromebooks, Sorry Skylake

More in Tux Machines

Programming/Development Leftovers

  • ‘I code in my dreams too’, say developers in Jetbrains State of Developer Ecosystem 2019 Survey
    Last week, Jetbrains published its annual survey results known as The State of Developer Ecosystem 2019. More than 19,000 people participated in this developer ecosystem survey. But responses from only 7000 developers from 17 countries were included in the report. The survey had over 150 questions and key results from the survey are published, complete results along with the raw data will be shared later. Jetbrains prepared an infographics based on the survey answers they received. Let us take a look at their key takeaways:
  • Python and "dead" batteries
    Python is, famously, a "batteries included" language; it comes with a rich standard library right out of the box, which makes for a highly useful starting point for everyone. But that does have some downsides as well. The standard library modules are largely maintained by the CPython core developers, which adds to their duties; the modules themselves are subject to the CPython release schedule, which may be suboptimal. For those reasons and others, there have been thoughts about retiring some of the older modules; it is a topic that has come up several times over the last year or so. It probably had been discussed even earlier, but a session at the 2018 Python Language Summit (PLS) is the starting point this time around. At that time, Christian Heimes listed a few modules that he thought should be considered for removal; he said he was working on a PEP to that end. PEP 594 ("Removing dead batteries from the standard library") surfaced in May with a much longer list of potentially dead batteries. There was also a session at this year's PLS, where Amber Brown advocated moving toward a much smaller standard library, arguing that including modules in the standard library stifles their growth. Some at PLS seemed to be receptive to Brown's ideas, at least to some extent, though Guido van Rossum was apparently not pleased with her presentation and "stormed from the room".
  • When and How to Win With New Programming Languages
  • Understanding Data Ops and it's impact on Application Quality

Latest Security FUD

Linux Foundation, Kernel, and Linux Plumbers Conference

  • Tech Giants Join Linux Foundation's Connected-Cities Efforts [Ed: Just surveillance capitalism inside Zemlin's PAC. Reminder: the spokesperson of the "Linux" Foundation is the former spokesperson of James Clapper.]
  • Generalized events notification and security policies
    Interfaces for the reporting of events to user space from the kernel have been a recurring topic on the kernel mailing lists for almost as long as the kernel has existed; LWN covered one 15 years ago, for example. Numerous special-purpose event-reporting APIs exist, but there are none that are designed to be a single place to obtain any type of event. David Howells is the latest to attempt to change that situation with a new notification interface that, naturally, uses a ring buffer to transfer events to user space without the need to make system calls. The API itself (which hasn't changed greatly since it was posted in 2018) is not hugely controversial, but the associated security model has inspired a few heated discussions.
  • Detecting and handling split locks
    The Intel architecture allows misaligned memory access in situations where other architectures (such as ARM or RISC-V) do not. One such situation is atomic operations on memory that is split across two cache lines. This feature is largely unknown, but its impact is even less so. It turns out that the performance and security impact can be significant, breaking realtime applications or allowing a rogue application to slow the system as a whole. Recently, Fenghua Yu has been working on detecting and fixing these issues in the split-lock patch set, which is currently on its eighth revision. [...] With a split lock, the value needs to be kept coherent between different CPUs, which means assuring that the two cache lines change together. As this is an uncommon operation, the hardware design needs to take a special path; as a result, split locks may have important consequences as described in the cover letter of Yu's patch set. Intel's choice was to lock the whole memory bus to solve the coherency problem; the processor locks the bus for the duration of the operation, meaning that no other CPUs or devices can access it. The split lock blocks not only the CPU performing the access, but also all others in the system. Configuring the bus-locking protocol itself also adds significant overhead to the system as a whole. On the other hand, if the atomic operation operand fits into a single cache line, the processor will use a less expensive cache lock. This all means that developers may increase performance and avoid split locks by actions like simply correctly aligning their variables.
  • Real-Time Microconference Accepted into 2019 Linux Plumbers Conference
    We are pleased to announce that the Real-Time Microconference has been accepted into the 2019 Linux Plumbers Conference! The PREEMPT_RT patch set (aka “The Real-Time Patch”) was created in 2004 in the effort to make Linux into a hard real-time designed operating system. Over the years much of the RT patch has made it into mainline Linux, which includes: mutexes, lockdep, high-resolution timers, Ftrace, RCU_PREEMPT, priority inheritance, threaded interrupts and much more. There’s just a little left to get RT fully into mainline, and the light at the end of the tunnel is finally in view. It is expected that the RT patch will be in mainline within a year, which changes the topics of discussion. Once it is in Linus’s tree, a whole new set of issues must be handled. The focus on this year’s Plumbers events will include:

Renaming openSUSE

At the 2019 openSUSE Conference, the openSUSE board discussed governance options at length. There will evidently be an official statement on its conclusions in the near future, but that has not been posted as of this writing. It would appear, though, that the board chose a foundation structure over the other options. A German registered association (e. V.) would have been easier to set up than a foundation, but an association has weaker restrictions so it could potentially shift its focus away from the openSUSE mission. Joining another umbrella group seemingly lacked appeal from the beginning, as did the option of doing nothing and leaving things as they are now. The stated purpose of the foundation is to make it easier for openSUSE to accept donations and manage its own finances — things that are hard for the project to do now. The foundation structure, in particular, allows the project to enshrine its core objectives (such as support for free software) into the DNA of the organization, making it hard to divert the foundation toward some other goal. A foundation also allows openSUSE to retain its current governing board and membership structure. In the absence of an official statement from the board, details on the decision and the reasoning behind it can be had by watching this YouTube video of a question-and-answer session with the board at the openSUSE Conference. One motivation for the change that wasn't highlighted in the board session, but which was an undercurrent in the discussions leading up to it, is a desire for more independence from SUSE in general driven by concerns about what the company might do in the future. Such worries are not entirely irrational, even though by all accounts SUSE management is fully supportive of openSUSE now. A company's attitude can change quickly even in the absence of external events like a change of ownership. If SUSE were to be sold yet again, the new owners could take a rather dimmer view of the openSUSE project. Read more