Language Selection

English French German Italian Portuguese Spanish

Roy Schestowitz's blog

Windows-Shocked

Filed under
Site News

There are rogue bots hammering on this site all day long. It has gone on for quite a few days and it is getting worse. The bots are getting harder to block. Strategies are changing. They are all acting like zombies/botnet and they all have a "Microsoft Windows" in their HTTP header.

The corporate media seems preoccupied with a bug in GNU Bash. It predicts gloom and doom, just as it did when there was a bug in OpenSSL that Microsoft partners dubbed "heartbleed" (although not so much actually happened in terms of damages).

Perhaps it is time to remind that media that Microsoft, with its back doors, is causing turbulence on the Web. Among the outcomes there are GNU/Linux Web sites that are brought down, with administrators who work around the clock trying to block Windows-running PCs from trying to take down their sites.

Rogue Bots

Filed under
Site News

Aggregators in Tux Machines have been universally disabled (temporarily we hope) after a week or so of heavy load that took the site down (well, over capacity and hence not accessible). The culprit seems to be mostly -- although not exclusively -- a bunch of bots that hammer on the aggregators with spammy requests. It's sad that so many hours need to be spent just keeping script kiddies out of the site, resulting in fewer bits of output, slower pageloads (performance degradation), and restlessness (monitoring alerts all day long), not to mention crafting of rules that merely keep the site running. Running Tux Machines is not quite as peaceful and trivial/simple as it may seem from the outside. It's like a full-time job, or at least it feels like it, especially whenever the site gets flooded by rogue bots, necessitating special attention 24/7.

Recent Changes in Tux Machines

Filed under
Site News

Work

TODAY we have taken a bit of a break. It's Sunday after all. But here is a bit of a site status update.

The site's design has evolved a bit and it hopefully makes navigation a little better. SPAM is still a problem, but we do our best to keep it out of the sight of visitors. It's the result of a permissive policy that lets everyone publish a story, blog post, etc.

In terms of server load, we are still coping most of the time, but sometimes there's a flood of SPAM/rogue traffic that renders the server virtually unreachable. We use some ad hoc filters for to address this nuisance, but if we are away, then the site can be paralysed for a long time. We still need to find better solutions to that.

Thanks in advance for any feedback you may have and thanks for reading Tux Machines.

It's Summer Again

Filed under
Site News

THE WEATHER has been getting more pleasant and the news too is pleasant these days. Software patents are in a state of perpetual demise, Microsoft is dealing with its large-scale demise (layoffs also), FOSS is being adopted by very large nations (Russia and China are among them), the UK has adopted OpenDocument Format as the standard, and our family benefits from government migrations to FOSS (Rianne and I work through a FOSS specialist).

While it may seem like the FOSS world is quiet (judging by the volume of news), the truth of the matter is that FOSS professionals are busy migrating many systems from proprietary to FOSS. These people are committed to the cause not just with words but also with actions.

Tux Machines, realising that games for GNU/Linux are now a dozen a week (not literally), lumps together gaming news. Android, being a Linux-based platform with huge worldwide impact, receives frequent mentions. If anyone wishes to suggest other editorial priorities, please share with us in the comments.

July's Record

Filed under
Site News

TODAY was the last day of the log rotation. The uncached requests to Apache (bypassing Varnish proxy) exceeded the record by a huge gap (around 20%) and nearly reached 300 megabytes.

It is reassuring and gratifying to know that our readers base is expanding each week and we welcome submissions (news, blogs, etc.), which can be automatically pushed to the front page by any subscriber.

Logo Concepts

Filed under
Just talk

More below...

TuxMachines Record Traffic

Filed under
Site News

FIVE days ago TuxMachines turned 10 years old. Rianne and I were on holiday in Scotland at the time, but were still able to keep the site up to date, owing to a Wi-Fi connection which we had to work exceptionally hard for (an open Wi-Fi connection is hard to find in the UK, especially one that enables anonymous use).

Running the site requires a lot of dedication because in order to stay up-to-the-minute TuxMachines requires non-ending research/survey of news. It's truly life-changing, potentially affecting the first hours of the morning and the little hours of the night. Sometimes it affects holidays and every couple of days I browse through news and post links in-between sets at the gym. Both Rianne and I are very dedicated to the site.

Since this site keeps growing in size and in traffic (the past week saw traffic climbing 20% above the previous record) it's all worthwhile at the end, and we have no intention of slowing down. What's more, seeing how Linux expands in use (and clout) around the world assures us that efforts to popularise GNU/Linux are succeeding.

'Free' Wi-Fi Usually Not Free Anymore

Filed under
Site News

Trafford Centre

SEVERAL days ago we visited Trafford Centre, which is a large shopping mall in Greater Manchester. The place is quite nice as it embodies very modern (yet classic) ornamental features, encompassing the best of outdoor and indoor decorations. It's all geared up towards consumerism, but there is also a nice cinema there. Now, here's the deal. Upon entering the mall one cannot help noticing that there is strong, universal Wi-Fi signal. Let's leave aside health implications. It's the same in other malls, such as the Arndale Centre near our house. It is also the same at airports, but if there is no payment needed for the Wi-Fi, then the user's identity is requested (if a payment is made, then the payment itself exposes the user's identity).

Trafford CentreFollowing basic principles and common sense, I gave some fake details so that I can use the 'free' Wi-Fi anonymously and log into Tux Machines (checking the latest), but I not help wondering, still. Given what we know about NSA- and GCHQ-centric plans for surveillance on in-flight Wi-Fi, what are the chances that users' identities are being requested not just for marketing purposes but also for surveillance? It is becoming very hard to access the Net anonymously now. The UK is cracking down on 'free' Wi-Fi, saying that it facilitates copyright infringement and our home hub, which is open for all to use (no password needed), keeps warning us that it is "not secure" (because it facilitates sharing). This is actively being discouraged if not forbidden. In all sorts of beverage-serving places (hot or cold, or alcoholic) and restaurants it is getting hard to gain anonymous Wi-FI access and the only way I've found (out of curiosity) to attain anonymous Wi-Fi use is First Class in high-speed British rail, provided one purchases the train ticket with cash. Similarly, it is getting harder to purchase groceries with cash here, at least without being penalised (not receiving a discount in exchange for identifying cards like Nectar). It sure seems like the very idea of anonymity here is becoming synonymous with crime. For experimental reasons I researched which shops in the UK still enable people to purchase a mobile phone anonymously. It's not easy, but it is still possible. Maybe it's no longer possible because I haven't surveyed the shops in almost 3 years.

We are entering a new unprecedented norm as those in power gradually phase in scary forms of governance in society, where the assumption is that anonymity deserves to be maligned and people should always identify themselves everywhere (also enable tracking of themselves by carrying a mobile phone) so as to avoid looking "suspicious". That's the mentality of mass surveillance that people have become accustomed to (and rather apathetic towards) in the UK.

It's stuff like this that made me exceptionally stubborn about deleting server logs in Tux Machines and not connecting to any third-party entity (e.g. with interactive social buttons, cookies), unlike most other GNU/Linux/FOSS sites.

Tux Machines Turns 10 in Exactly One Month

Filed under
Site News

A drunken penguin

THIS past week was not a bad week at all. There was lots to cover (without compromising focus and s/n ratio) and it was our biggest week ever (since we carried on from Susan) in terms of traffic, with as many visitors in 5.5 days as in the previous record for a week (7 days). Based on whois, the Creation Date of Tux Machines is 2004-06-10 05:40:40, so we are exactly a month away from an important anniversary.

We don't track visitors, we just look at the size of uncached traffic logs (no unique IPs, only one IP -- that of the Varnish server -- is shown for everyone) before they are deleted for good, which would be every 4-5 weeks (logrotate). Privacy preservation is a conscious decision for us.

Thanks to everyone for choosing us for news. We enjoy running the site and we hope you enjoy following it. Running the site requires a lot of dedication, including posting while out of the house (wirelessly) or staying up late at night to catch up with the latest headlines. Rianne sometimes stays awake until 3 AM because she wants to ensure readers are being informed.

Secret Back Doors in Android

Filed under
Just talk

I am everything but a Google basher and I spent a lot of my life descending deep into research of Google foes, Google smear campaigns, lawsuits by proxy, and antitrust actions by proxy. I also advocate Android, but in recent years I have been increasingly concerned about the direction it is taking. I wish to share my latest concern. It relates to what the media characterises as "anti-theft" but is actually a facility to kill phones in a protest or convert them into hostile listening devices. Technology impacts human rights and those who control technology can be tempted to control humans.

Google habitually updates my tablet. It is a Nexus 7 tablet which Google invites itself to update remotely (shame on me for not installing Replicant, but this device does not support it yet). It is not a 3G tablet and it does not have two operation systems (unlike mobile phones) or even a carrier tracking its location all the time. It's a purely Android device with no network tying. It is network-agnostic. I only bought it because in order to replace my PDA (for over a decade) I wanted a device that is not a tracking device. Phones were out of the question.

Networks don't track the tablet. Google, however, is always out there, fully able to identify the connected user (latched onto a Gmail address because of Play), modifying the software without even the user's consent (the user is sometimes prompted to boot, without being able to opt out of the core update itself).

The update in itself is not a problem. What's problematic is its effect.

Following the latest Google update (which I was given no option to reject) I noticed that Google had added a remote kill switch as an opition. It was enabed by default. "Allow remote lock and erase" is what Google calls it and it is essentially working like a back door. Google and its partners in government are gaining a lot of power not over a smartphone but over a tablet.

The significance of this is that not only phones should be assumed to be remotely accessible for modification, including for example additional back doors. What's more, some devices that were sold without this functionality silently have it added. According to the corporate press, the FBI remotely turns Android devices into listening devices and it is getting simpler to see how.

NSA and PRISM destroy our computing. We definitely need to demand Free software, but we should go further by asking for audits, rejecting user-hostile 'features' like DRM, 'secure' boot, and kill switches. I gradually lose any remaining trust that I had in Google and even Free software such as Android.

Tux Machines This Month

Filed under
Site News

Tux Machines

THE Web site is still experiencing a resurgence/growth while bits and pieces are being modernised to take advantage of CSS3. This site's Netcraft ranking climbed sharply to 8479th and this month alone traffic climbed by about 25%. Thanks to all those who choose Tux Machines as their source of news.

MakuluLinux 6 Codename "Imperium" MATE 1.8 Edition Released Tomorrow

Filed under
News

MakuluLinux

LAST night I received a timely recommendation of the Debian-based MakuluLinux. For more details and background see the main page of MakuluLinux, this recent video review, and a very brief announcement of an upcoming release with MATE, which is described in this old post.

There is a lot more information out there about MakuluLinux Mate Edition, whose 1.8 version is being planned/finalised/slated for release this Monday. There isn't yet an official site announcement, but the links to the Preview Edition will hopefully help those who want to try out the distro. It is a "true" community distro of GNU/Linux.

Tux Machines Turns 10 in a Couple of Months

Filed under
Site News

Ten

THERE HAS always been something different in Tux Machines. Rather than strictly follow what corporate media said was the "big" story, Tux Machines paid attention to blogs large and small, trying to extract the signal out of the noise and the hype (stories that 'sell' better, such as vulgar language from Mr. Torvalds). Tux Machines was the first site to visit (back when I was merely a visitor) to look for news in. If there is a blog, site, mailing list etc. that you think we should follow (syndicate), please let us know because we are always looking for more diverse sources, especially ones that offer original stories, not repetition.

There will soon be an important anniversary for this site, which is still growing not only in terms of size but also in terms of readership. We stay committed to the scope as explained yesterday in the update to this page and we are hoping to keep serving for another 10 (or tens of) years to come. Today we added a "view as PDF" functionality. Any ideas for improving the site (in terms of functionality, layout, stories selection) would be much appreciated.

Manchester and Computing

Filed under
Just talk

Manchester's role in the history of computing is not widely recognised. I spent several years working in Manchester Computing and I studied where the first programmable computer was built (by Kilburn, whom the building was later named after). One of my colleagues at Manchester Computing (MCC) was the person who was first to build and distribute a GNU/Linux distribution (combining both GNU and Linux) and yesterday I met and spoke to one of the earlier PC distributors from across the road (supplier for Manchester Computing). Right here at the centre of Manchester a lot of the early milestones of computing took place (Turing also), but Manchester became better known for the splitting of atoms, the football teams, famous bands like Oasis, and the industrial revolution. A few days ago Rianne and I visited the local museum which demonstrates the industrial revolution (photo above from this album); what we really need here, however, are more museums documenting Manchester's role in modern computing. This city deserves more credit.

Signal-to-Noise Ratio

Filed under
Site News

Non-cached site traffic still increasing

Stats chart for Tux Machines

Tux Machines has been my favourite GNU/Linux news site since I first discovered it around 2005. I publicly recommended Tux Machines for several years. Susan knew how to select important stories and she contributed objective articles of her own.

Running Tux Machines

Filed under
Site News

Roy Schestowitz

TUX Machines has become an integral part of our life right here in this humble home. It's a rewarding experience but also a demanding experience. I personally write my articles in the lounge (which is no 'press room') and it requires many hours of digging and researching news. In Tux Machines, unlike in Techrights for example, it's mostly about finding news of high relevance and importance, and finding them fast! Timing counts. We don't want readers to waste their time wading/going through irrelevant, unimportant and out-of-date reports.

24/7 coverage of news is easy for us. Rianne works mostly at daytime, whereas I usually work at nights (customers are mostly government/public sector and they require 24/7 coverage). When Rianne is working I take over the responsibilities at Tux Machines and vice versa. We swap responsibilities like this when it comes to housework as well; we work out together when we are out of the house (also separately in terms of gym sections, e.g. cardiovascular/weights). This week we go to yoga classes as much as 5 times, but we usually just to Town for other facilities like pool, table tennis, sauna (men and women separately), gym, etc. This is our main escape from Tux Machines; given Wi-Fi (scarce coverage but definitely existent in Manchester City Centre), we sometimes update Tux Machines while out of the house as well.

The site forums are now open for participation and every registered member can add blog posts and push them to the front page (now that we've got the spam epidemic under control). Please do consider participating. This week, as in previous weeks, we are seeing a ~10% growth in traffic (week-to-week), perhaps owing to the slight redesign, loading speeds (Varnish cache), and very frequent updates. We check for news once in a few hours in order to keep abreast of breaking events.

Running Tux Machines will hopefully become more of a community effort over time. Anyone who is logged in can now submit stories. Unless this gets abused by spammers, we will keep it that way.

Mollom Works

Filed under
Site News

Drupal's very own Mollom is a Free/Open Source (collaboratively-developed and freely-shared) software for battling script kiddies and fighting against SPAM. The past 2 weeks were difficult because spammers exploited the fact that we had opened up the site for registration/subscription (to leave comments). After exploring some options for dealing with the problem (spam making it to the front page even!) we found that Mollom was good enough to eliminate almost 100% of all of spam (so far). Hence, for the time being, it seems safe to say now that we beat the script kiddies. Thanks, Mollom!

Mollom

First Month on the New Server (Updated)

Filed under
Site News

Tux Machines behind Varnish cache proxy

Chart for Tux Machines

Summary: Tux Machines growth and a note regarding SPAM prevention after a week or so of experiments

Here are the first four weeks' log sizes, plotted with LibreOffice and demonstrating week-to-week growth since the site's nameservers changed and the server moved to CoPilotCo. After 4 weeks all logs get deleted (logrotate) to ensure privacy through lack of data retention (except short term in case of DDOS).

Opening Up Communications (Updatedx5)

Filed under
Site News

Script kiddies can't get their way

Diversity

Summary: Script kiddies made it impractical to manage comments and forum posts; we are trying to tackle this issue today

IN ANOTHER attempt to restore user registrations, this time on the new server which has just been configured for mail, we are enabling anyone to quickly self-register (takes less than a minute and requires no verification), then immediately post comments, forum posts, etc.

Site Update (Updatedx2)

Filed under
Site News

Newspaper

Summary: Recent changes at Tux Machines, in just a nutshell

INSPIRED in part by Slashdot, we recently added topical icons to submissions, applying these changes retroactively to over 50,000 older pages. The idea was, this can improve orientation by helping to quickly associate text with topics. More minor modifications were made as well, some textual and some layout related. They are subtle but they can be seen. After receiving feedback regrading icons size we made further modifications. Regarding social media buttons, some of the ones we initially found were unbelievably privacy-infringing (allowing Google, Facebook, Twitter etc. to see visitors of this site), so we disabled them immediately and replaced them with static buttons. Right now we can assure that whenever loading pages in this Web site nothing except our security-aware network gets contacted. We share no data about visitors (with anyone) and Apache logs get shredded for good after a few weeks, leaving sufficient trail just in case of attacks on the site, which would merit investigation. Log rotation is similarly privacy-respecting at the cache level, which leads to the following point.

Today, after the above changes had been made and stability attained (there were some network disruptions yesterday), we also updated Drupal, ensuring it is secure and fully up to date (the latest minor bugfix release is a month old). There is still an issue with Varnish and until we tackle this issue users who are not logged in might be getting error pages. One way to overcome this is to append "?something" to the URL requested. This bypasses the Varnish cache until we finish our investigation of this issue and resolve it for good.

Update: The issue with Varnish turns out to be a conflict between two caching layers. It's fixed now. If you spot an issue, still, please let us know.

Update #2: Yesterday we identified another issue and soon thereafter fixed it. After Twitter syndication had failed we realised that RSS feeds were not standards-compliant, due to a blank line at the start of each generated page in Drupal. This is a common issue and it is a nightmare to debug (requires a complete code review with help of GNU utilities like grep). After 4 hours of investigation I found the culprit and fixed the coding error. RSS feeds are back.

Syndicate content

More in Tux Machines

LWN: Spectre, Linux and Debian Development

  • Grand Schemozzle: Spectre continues to haunt

    The Spectre v1 hardware vulnerability is often characterized as allowing array bounds checks to be bypassed via speculative execution. While that is true, it is not the full extent of the shenanigans allowed by this particular class of vulnerabilities. For a demonstration of that fact, one need look no further than the "SWAPGS vulnerability" known as CVE-2019-1125 to the wider world or as "Grand Schemozzle" to the select group of developers who addressed it in the Linux kernel. Segments are mostly an architectural relic from the earliest days of x86; to a great extent, they did not survive into the 64-bit era. That said, a few segments still exist for specific tasks; these include FS and GS. The most common use for GS in current Linux systems is for thread-local or CPU-local storage; in the kernel, the GS segment points into the per-CPU data area. User space is allowed to make its own use of GS; the arch_prctl() system call can be used to change its value. As one might expect, the kernel needs to take care to use its own GS pointer rather than something that user space came up with. The x86 architecture obligingly provides an instruction, SWAPGS, to make that relatively easy. On entry into the kernel, a SWAPGS instruction will exchange the current GS segment pointer with a known value (which is kept in a model-specific register); executing SWAPGS again before returning to user space will restore the user-space value. Some carefully placed SWAPGS instructions will thus prevent the kernel from ever running with anything other than its own GS pointer. Or so one would think.

  • Long-term get_user_pages() and truncate(): solved at last?

    Technologies like RDMA benefit from the ability to map file-backed pages into memory. This benefit extends to persistent-memory devices, where the backing store for the file can be mapped directly without the need to go through the kernel's page cache. There is a fundamental conflict, though, between mapping a file's backing store directly and letting the filesystem code modify that file's on-disk layout, especially when the mapping is held in place for a long time (as RDMA is wont to do). The problem seems intractable, but there may yet be a solution in the form of this patch set (marked "V1,000,002") from Ira Weiny. The problems raised by the intersection of mapping a file (via get_user_pages()), persistent memory, and layout changes by the filesystem were the topic of a contentious session at the 2019 Linux Storage, Filesystem, and Memory-Management Summit. The core question can be reduced to this: what should happen if one process calls truncate() while another has an active get_user_pages() mapping that pins some or all of that file's pages? If the filesystem actually truncates the file while leaving the pages mapped, data corruption will certainly ensue. The options discussed in the session were to either fail the truncate() call or to revoke the mapping, causing the process that mapped the pages to receive a SIGBUS signal if it tries to access them afterward. There were passionate proponents for both options, and no conclusion was reached. Weiny's new patch set resolves the question by causing an operation like truncate() to fail if long-term mappings exist on the file in question. But it also requires user space to jump through some hoops before such mappings can be created in the first place. This approach comes from the conclusion that, in the real world, there is no rational use case where somebody might want to truncate a file that has been pinned into place for use with RDMA, so there is no reason to make that operation work. There is ample reason, though, for preventing filesystem corruption and for informing an application that gets into such a situation that it has done something wrong.

  • Hardening the "file" utility for Debian

    In addition, he had already encountered problems with file running in environments with non-standard libraries that were loaded using the LD_PRELOAD environment variable. Those libraries can (and do) make system calls that the regular file binary does not make; the system calls were disallowed by the seccomp() filter. Building a Debian package often uses FakeRoot (or fakeroot) to run commands in a way that appears that they have root privileges for filesystem operations—without actually granting any extra privileges. That is done so that tarballs and the like can be created containing files with owners other than the user ID running the Debian packaging tools, for example. Fakeroot maintains a mapping of the "changes" made to owners, groups, and permissions for files so that it can report those to other tools that access them. It does so by interposing a library ahead of the GNU C library (glibc) to intercept file operations. In order to do its job, fakeroot spawns a daemon (faked) that is used to maintain the state of the changes that programs make inside of the fakeroot. The libfakeroot library that is loaded with LD_PRELOAD will then communicate to the daemon via either System V (sysv) interprocess communication (IPC) calls or by using TCP/IP. Biedl referred to a bug report in his message, where Helmut Grohne had reported a problem with running file inside a fakeroot.

Flameshot is a brilliant screenshot tool for Linux

The default screenshot tool in Ubuntu is alright for basic snips but if you want a really good one you need to install a third-party screenshot app. Shutter is probably my favorite, but I decided to give Flameshot a try. Packages are available for various distributions including Ubuntu, Arch, openSuse and Debian. You find installation instructions on the official project website. Read more

Android Leftovers

IBM/Red Hat and Intel Leftovers

  • Troubleshooting Red Hat OpenShift applications with throwaway containers

    Imagine this scenario: Your cool microservice works fine from your local machine but fails when deployed into your Red Hat OpenShift cluster. You cannot see anything wrong with the code or anything wrong in your services, configuration maps, secrets, and other resources. But, you know something is not right. How do you look at things from the same perspective as your containerized application? How do you compare the runtime environment from your local application with the one from your container? If you performed your due diligence, you wrote unit tests. There are no hard-coded configurations or hidden assumptions about the runtime environment. The cause should be related to the configuration your application receives inside OpenShift. Is it time to run your app under a step-by-step debugger or add tons of logging statements to your code? We’ll show how two features of the OpenShift command-line client can help: the oc run and oc debug commands.

  • What piece of advice had the greatest impact on your career?

    I love learning the what, why, and how of new open source projects, especially when they gain popularity in the DevOps space. Classification as a "DevOps technology" tends to mean scalable, collaborative systems that go across a broad range of challenges—from message bus to monitoring and back again. There is always something new to explore, install, spin up, and explore.

  • How DevOps is like auto racing

    When I talk about desired outcomes or answer a question about where to get started with any part of a DevOps initiative, I like to mention NASCAR or Formula 1 racing. Crew chiefs for these race teams have a goal: finish in the best place possible with the resources available while overcoming the adversity thrown at you. If the team feels capable, the goal gets moved up a series of levels to holding a trophy at the end of the race. To achieve their goals, race teams don’t think from start to finish; they flip the table to look at the race from the end goal to the beginning. They set a goal, a stretch goal, and then work backward from that goal to determine how to get there. Work is delegated to team members to push toward the objectives that will get the team to the desired outcome. [...] Race teams practice pit stops all week before the race. They do weight training and cardio programs to stay physically ready for the grueling conditions of race day. They are continually collaborating to address any issue that comes up. Software teams should also practice software releases often. If safety systems are in place and practice runs have been going well, they can release to production more frequently. Speed makes things safer in this mindset. It’s not about doing the “right” thing; it’s about addressing as many blockers to the desired outcome (goal) as possible and then collaborating and adjusting based on the real-time feedback that’s observed. Expecting anomalies and working to improve quality and minimize the impact of those anomalies is the expectation of everyone in a DevOps world.

  • Deep Learning Reference Stack v4.0 Now Available

    Artificial Intelligence (AI) continues to represent one of the biggest transformations underway, promising to impact everything from the devices we use to cloud technologies, and reshape infrastructure, even entire industries. Intel is committed to advancing the Deep Learning (DL) workloads that power AI by accelerating enterprise and ecosystem development. From our extensive work developing AI solutions, Intel understands how complex it is to create and deploy applications for deep learning workloads. That?s why we developed an integrated Deep Learning Reference Stack, optimized for Intel Xeon Scalable processor and released the companion Data Analytics Reference Stack. Today, we?re proud to announce the next Deep Learning Reference Stack release, incorporating customer feedback and delivering an enhanced user experience with support for expanded use cases.

  • Clear Linux Releases Deep Learning Reference Stack 4.0 For Better AI Performance

    Intel's Clear Linux team on Wednesday announced their Deep Learning Reference Stack 4.0 during the Linux Foundation's Open-Source Summit North America event taking place in San Diego. Clear Linux's Deep Learning Reference Stack continues to be engineered for showing off the most features and maximum performance for those interested in AI / deep learning and running on Intel Xeon Scalable CPUs. This optimized stack allows developers to more easily get going with a tuned deep learning stack that should already be offering near optimal performance.