Language Selection

English French German Italian Portuguese Spanish

FOSS Force

Syndicate content
FOSS Force News Wire
Updated: 20 min 30 sec ago

How Listening Class Can Help International Employees To Boost Their Career

Monday 6th of February 2023 02:48:39 PM
Are you an international employee looking to advance your career? Check out this article for information on how listening classes can help you achieve your goals.

Security updates for Monday

Monday 6th of February 2023 02:41:17 PM
Security updates have been issued by Debian (libhtml-stripscripts-perl), Fedora (binwalk, java-1.8.0-openjdk, java-11-openjdk, java-17-openjdk, java-latest-openjdk, kernel, sudo, and syncthing), SUSE (syslog-ng), and Ubuntu (editorconfig-core, firefox, pam, and thunderbird).

You don't have to be clever to be a cybercriminal

Monday 6th of February 2023 02:18:56 PM
Cybercriminals don't need to be clever and use inventive hacking exploits to breach systems as organizations are making things too easy for them, says a new report. Intelligence-led computer security testing company SE Labs has released its annual Cyber Threat Intelligence report with a warning that CEOs need to take cybersecurity seriously or risk falling into the clutches of criminals eager to take their data and their money. The report finds half of US businesses don't take cybersecurity seriously and are largely led by company boards that still don't have an IT security plan. In the UK, this figure is… [Continue Reading]

14 Rust Tools for Linux Terminal Dwellers

Monday 6th of February 2023 02:00:48 PM
Rust-powered tools for the terminal? Here are some of the best options as alternatives to some popular command-line tools! The post 14 Rust Tools for Linux Terminal Dwellers appeared first on Linux Today.

New in Azure DevOps for Octopus Deploy v6

Monday 6th of February 2023 02:00:00 PM
In this post, you learn what's new in v6 of the Octopus Azure DevOps plugin being released this week, understand some of the decisions that went in to the updates, and get a quick tour of the updated plugin. The updates include: Octopus CLI is no longer required, and by extension, neither is the .NET Framework Octopus 2022.3+ is now a dependency (this is only for the v6 steps, not the earlier versions) There's a new step for running a Runbook If you read about our our third iteration of GitHub Actions for Octopus Deploy, some of these updates will sound familiar. Octopus CLI is no longer required Removing the dependency on the Octopus CLI is the biggest architectural change to v6 of the Octopus Azure DevOps plugin. Our steps no longer use the Octopus CLI to perform work. Instead, they interact with the Octopus API directly from TypeScript. This means your pipelines start and execute far quicker than before. It also means v6 of the steps has a dependency on Octopus Server 2022.3+, as it introduced the Executions API. You can still use the Octopus CLI, but you're no longer required to include the Octopus CLI Installer in your pipeline if you only need to use our other steps. The Octopus CLI Installer is still available for you to use if you have a script of your own that needs it. See more in the next section. We achieved a longstanding goal of full NodeJS support, eliminating the dependency on the .NET Framework. This removes compatibility issues caused by the deprecation of various .NET Framework versions, which have plagued customers in the past. The transition to NodeJS means smoother and more reliable software releases. Octopus CLI Installer now installs the Go-based CLI We recently moved our CLI implementation from C# to Go (for more information on why, please see Building Octopus CLI vNext). The Octopus CLI (octo) will remain supported until mid-2023. The Octopus CLI Installer v5 will continue to install the Octopus CLI (octo). If you have existing pipelines using the C#-based CLI, you can continue to use v5. Octopus CLI Installer v6 (or greater) will only install the new Go-based CLI (octopus). If you're writing new pipelines, we recommend using v6. The Go-based CLI (octopus) has new features and improvements missing from the C#-based CLI, however, there are some minor differences. If necessary, you can use these CLIs side-by-side. That is, you could include both v5 and v6 of the step in the same pipeline to get both CLIs. We did not update Invoke Octopus CLI command step to v6. The design of the new Go CLI leans into scripting concepts, like chaining inputs/outputs, and you can use it directly in script steps, so we made the decision not to update the Invoke Octopus CLI command step. We recommend using a script step in your pipeline and call octopus directly. Deployments and runbook runs In earlier versions of the plugin, the Create Release step supported the deploy-to parameter from the Octopus CLI (octo). Unfortunately, this brought with it all the other deployment-related concerns that the Octopus CLI (octo) supports. The switches for these additional concerns, though, aren't directly available. You had to know which switches you needed and enter them directly into an "Additional arguments", making the step complex and confusing. A key design consideration for the Executions API was to simplify things and formalize the requirements/inputs for specific actions. The v6 updates to the Azure DevOps steps reflect these changes directly and now have explicit fields for all supported settings. Key things to note: Create Octopus Release just creates a release Deploy Octopus Release just queues a deployment (as does the new Deploy Octopus Release to Tenants step, which we'll talk about more momentarily) The new Run Octopus Runbook step queues a run You can use the new Await Octopus Task Completion if you want to wait for tasks that you queued for deployments or runbook runs Tenanted deployments have different semantics to "standard" deployments. Primarily, they support a different multiplicity on the environments you can deploy to (standard can deploy to multiple environments, tenanted can only deploy to a single environment). To make this clear, we split them into separate steps, with clear names on the fields to make it clearer what each step supports. Again, this also directly reflects the way the Executions API functions. While this is the initial version of some of these steps, we decided to release them all as v6 to make it easier to reason about them as a matching set. The versions may diverge again over time as we move forward and make patches and updates to the steps individually. Chaining is a built-in feature A number of the steps now produce outputs, to enable chaining. The outputs are as follows: Step Outputs Description Pack (both Zip and NuGet) package_file_path The full path to the package that was created package_filename Just the filename of the package that was created Create Octopus Release release_number The release number (version) that was created Deploy Octopus Release server_tasks JSON array of objects with serverTaskId and environmentName Deploy Octopus Release to Tenants server_tasks JSON array of objects with serverTaskId and tenantName Run Octopus Runbook server_tasks JSON array of objects with serverTaskId, environmentName, and tenantName Await Octopus Deploy Task completed_successfully Whether the task(s) completed successfully or not server_task_results JSON representation of the tasks and their success. Schema: { "serverTaskId": , "tenantName": , "environmentName": , "successful": }.This is provided for scenarios like error handling. E.g. if you have a subsequent step that conditionally ran on failure of this step, it could use the JSON for things like logging, sending messages to Slack, etc .completed_successfully Contextual success flag for each task using the name of the environment or tenant, e.g Production.completed_successfully or UAT_Tenant_A.completed_successfully. Spaces in names are replaced with underscores We show you in more detail how to use the outputs in the examples below. Other changes Pack has been split We decided to separate the Zip and NuGet package creation steps, for similar reasons to those mentioned above. Having the 2 in a single step leads to a more complex and confusing list of configuration fields. No more selectors Except for the Octopus service connection selector, we removed all selectors in the v6 versions of the steps. The selectors require Azure DevOps itself to connect to the Octopus instance. For customers with a self-hosted instance of Octopus behind a firewall, this is confusing and looks like things aren't going to work, but if they just type a name into the field it may work at runtime (that is, it may work when using a self-hosted build agent, if that agent is behind the firewall and can connect to Octopus). This felt overly complex for the potential little gain for some customers, so we reverted all fields to strings. Create Release project name We noticed an inconsistency in the naming of the Create Release field while working on these steps. You don't notice this in the classic view, but it becomes obvious when you're using YAML. The Create Release step used ProjectName, but all the other steps use Project as the name of this field. We decided that while it's a slight inconvenience for an upgrade, it makes life easier in the future to rename the field on the Create Release step. Migrating to v6 No existing step versions have changed. You shouldn't encounter any changed behavior on upgrade of the plugin. You will encounter some changes when migrating from older versions to v6,though. We tried to minimize this while balancing against consistency and ease of use going forward. In the classic editor, if you haven't saved the pipeline, you haven't lost any data. So, if you switch to v6 and lose something or aren't happy with the new settings, you can refresh the page to reload the original version and data. In YAML, you just revert the text changes to go back. Fields use names not IDs Anyone who used the classic view for earlier steps and then looked at their YAML representation might notice some fields contain names and some contain IDs. Some can even be either, which is a side-effect of the selectors. If you select a value from the list, it will contain an ID if you type directly into the same field, although you'll probably enter a name (as you would likely do in YAML). The Executions API only supports names, not IDs, to remove the need for lots of lookups. As a result, the steps also only support names now. If you're upgrading an earlier version of a step to v6 in a classic pipeline and used a selector in the past, you'll see an ID appear in the field, and you have to edit the value to be the name. Metadata vs Build Information When the Build Information feature was first released, it was called Package Metadata. We kept some remnants of that for backward compatibility. This is visible today in the YAML steps, where you use OctopusMetadata as the step identifier. From v6 forward, the YAML ID for this step will be OctopusBuildInformation. (OctopusMetadata will continue to work for v4 and v5, so existing pipelines should not be impacted). In the classic editor, you won't be able to select v6 from the dropdown on an existing v4/v5 step. The plugin now sees them as separate and you have to add a new Build Information step (the one that doesn't have legacy in the title/description) and copy the values across. We apologize for any inconvenience this causes as we balance it against ease of understanding moving forward, especially given the prevalence of YAML pipelines. Additional arguments In prior versions of the steps, this field served as a fallback option for inputting arguments that weren't represented by specific fields. With the transition away from the CLI, this field is obsolete and has been deprecated. Despite its obsolescence, the decision was made to retain the field on steps where it was likely used to minimize disruption. For key things, like packages during release creation and variables when deploying a release, we tried our best to parse the existing values and union the data into that provided by the new fields for these values. You'll see a warning in the logs to let you know this has happened and we recommend you move the values into the new fields at your earliest convenience. Sample pipeline walkthrough In this walkthrough, we use a simple ASP.NET web application as an example. At a high level the pipelines is: "Packaging" using the .NET tooling Using an Octopus Pack step to get the output into a package file that Octopus can work with Pushing that package file to Octopus, along with some build information Creating a release using that package Queueing deployments for that release Waiting for those queued tasks to complete For brevity, we include the .NET build/package steps in the YAML version of the pipeline, but skip screenshots for the same steps in classic mode. Let's start with the complete YAML and then we'll mention the parts of interest. steps: - task: DotNetCoreCLI@2 displayName: 'dotnet restore' inputs: command: restore projects: 'source' - task: DotNetCoreCLI@2 displayName: 'dotnet build' inputs: command: build projects: 'source' arguments: '--configuration Release' - task: DotNetCoreCLI@2 displayName: 'dotnet publish' inputs: command: publish projects: 'source' arguments: '--configuration Release --output $(build.artifactstagingdirectory)' publishWebProjects: false zipAfterPublish: false modifyOutputPath: false - task: OctopusPackZip@6 name: pkg displayName: 'Package Zip' inputs: PackageId: $(pkgId) PackageVersion: '$(Build.BuildNumber)' SourcePath: '$(build.artifactstagingdirectory)' OutputPath: drop - task: OctopusPush@6 displayName: 'Push Packages to Octopus' inputs: OctoConnectedServiceName: $(connectionName) Space: $(spaceName) Packages: '$(pkg.package_file_path)' - task: OctopusBuildInformation@6 displayName: 'Push Package Build Information to Octopus' inputs: OctoConnectedServiceName: $(connectionName) Space: $(spaceName) PackageId: $(pkgId) PackageVersion: '$(Build.BuildNumber)' - task: OctopusCreateRelease@6 name: create_release displayName: 'Create Octopus Release' inputs: OctoConnectedServiceName: $(connectionName) Space: $(spaceName) Project: $(octoProject) Packages: '$(pkgId):$(Build.BuildNumber)' - task: OctopusDeployRelease@6 name: deploy displayName: 'Deploy Octopus Release' inputs: OctoConnectedServiceName: $(connectionName) Space: $(spaceName) Project: $(octoProject) ReleaseNumber: '$(create_release.release_number)' Environments: | Dev Staging - task: OctopusAwaitTask@6 displayName: 'Await Octopus Deploy Task' inputs: OctoConnectedServiceName: $(connectionName) Space: $(spaceName) Step: deploy Key technical things to note are: Steps you want to reference output variables from must have a name defined, for example, name: create_release. You then use that name to reference the variable in later steps. For example, ReleaseNumber: '$(create_release.release_number)' The Await step understands the structure of the output variables emitted by our deploy/runbook run steps and handles the variable binding internally. Therefore, you only need to provide it with the name of the deploy/runbook run step, not a variable binding Inputs with pluralized names support multiple values, each entered as a separate line (see Environments in the example) Use caution when naming your variables. We learned the hard way that having a variable named packageId declared has special meaning to dotnet restore. Classic pipeline Below is a view of the same process modeled in a classic pipeline. For brevity, we'll only dig into vital details. They each contain fields that align with the inputs illustrated in the YAML pipeline. With the classic pipelines, it's important to understand how the output variable chaining works. On the steps that support output variables, you find the following panel at the bottom of the step. This is Azure DevOps detecting that we declared the step supports output variables and providing a way to connect the steps together. It's asking for the equivalent to the name property in YAML, a unique name in the pipeline for this step. You then use that name in later steps in variables bindings, in the same way you reference them in YAML. As noted in the YAML example, the Await step has internal knowledge of the output variables structure from the deploy/runbook run steps, so you use the step reference name. Conclusion The new steps and updates to the Octopus Azure DevOps plugin improve the automation of deployment processes, task execution, and the creation of packages. This gives you more consistency and a more seamless user experience. Additionally, the marketplace listing for the plugin is undergoing a comprehensive revamp to include detailed information on all input and output variables, to aid you if you're using YAML pipelines. Our goal with this release is to empower you with robust and user-friendly steps to manage your deployments, and we believe it will significantly enhance your experience. Happy deployments!

Gorgeous puzzler Bonfire Peaks getting a 3-part DLC starting March 2nd

Monday 6th of February 2023 01:38:54 PM
Easily one of the best puzzle games to release back in 2021 and frankly it's criminally overlooked, is set to get a whole lot bigger with the Lost Memories 3-part DLC.

New Slax Releases Make Persistent Changes Up to 10 Times Faster with DynFileFS

Monday 6th of February 2023 01:35:00 PM
Slax creator Tomas Matejicek announced today the general availability of two new versions of its minimalist distribution that promises a brand-new file system for persistent storage with the latest DynFileFS release.

It’s Time To Codify The ‘NY Times v. Sullivan’ Standard Into Law

Monday 6th of February 2023 01:26:08 PM
For all the misleading claims about “free speech under attack” in place where it is definitively not under attack (i.e., on social media sites, or via “cancel culture”), there are many areas in which free speech absolutely is under attack, and there may be no bigger one than the (relatively new!) movement to overturn the […]

Zero Wing, Twin Cobra and other Toaplan classics get upgraded for PC

Monday 6th of February 2023 01:22:17 PM
All your base are belong to us. Toaplan are having some absolute classics revived including Zero Wing, Out Zone, Twin Cobra and Truxton with a PC release and enhancements. Oh, and Native Linux support to ensure they're great on Steam Deck too.

Manage Systemd Services Using systemctl [With Examples]

Monday 6th of February 2023 01:17:45 PM
All the major Linux distributions, such as Ubuntu, Fedora, etc use the systemd init system today for managing and controlling various services while the system is running. In this guide, we explain the systemd commands you can use to manage systemd services using systemctl. Service management concept Systemd is the init system and service manager... The post Manage Systemd Services Using systemctl [With Examples] appeared first on Do not reproduce this post without permission.

Top 5 Live Streaming Applications for Ubuntu and Other Linux [2023 Edition]

Monday 6th of February 2023 01:13:47 PM
This post lists the top five live streaming applications for Ubuntu Linux with features, highlights, download details, and comparison. It is the best time to incorporate online video content for your business. Why? Because research suggests that the global online video market is growing at a rate of ~20% per year. And thanks to some... The post Top 5 Live Streaming Applications for Ubuntu and Other Linux [2023 Edition] appeared first on Do not reproduce this post without permission.

Superfluous Returnz is an unnecessary video game of a useless superhero

Monday 6th of February 2023 01:07:02 PM
French comedy point and click adventure Superfluous Returnz is all about a useless superhero and it's releasing on May 15th.

KDE Plasma: Full Featured Desktop That’s Surprisingly Easy on Resources

Monday 6th of February 2023 01:00:22 PM
KDE's Plasma desktop environment, once considered something of a resource hog, has more features than ever and is Linux's most configurable desktop, yet it's as easy on resources as relatively lightweight desktops such as Xfce.. The post KDE Plasma: Full Featured Desktop That’s Surprisingly Easy on Resources appeared first on FOSS Force.

The Current State Of Coreboot & Open-Source Firmware For AMD Hardware In 2023

Monday 6th of February 2023 01:00:00 PM
Michał Żygowski of firmware consulting firm 3mdeb presented at FOSDEM 2023 this weekend in Brussels. The focus of Żygowski's presentation for the Free Open-Source Developers' European Meeting was on the current client and server hardware state for AMD platforms with Coreboot / open-source firmware...

touchHLE is a new emulator for iPhone OS apps

Monday 6th of February 2023 12:50:28 PM
Want a way to emulate old Apple iOS apps and games? Well, touchHLE just had its first release to prevent some more things being lost to time.

Revisited: PyRadio – curses based internet radio player

Monday 6th of February 2023 12:43:44 PM
PyRadio is a cross-platform curses based internet radio player written in Python. Let's check out the current version. The post Revisited: PyRadio – curses based internet radio player appeared first on LinuxLinks.

Open source Transport Tycoon Deluxe remake OpenTTD v13.0 is out now

Monday 6th of February 2023 12:38:43 PM
Another classic free and open source game continues getting better, with the Transport Tycoon Deluxe remake OpenTTD version 13.0 out now.

Big 3 Public Cloud Providers Focus on What's Next

Monday 6th of February 2023 12:16:00 PM
With inflation and recession front and center for most organizations, how does the cloud fit in? AWS, Microsoft, and Google have a few ideas.

Linux Parallel CPU Bring-Up Shows Great Impact Bringing Up 1,920 Sapphire Rapids Cores

Monday 6th of February 2023 11:55:51 AM
After the prior kernel patches had stalled in their review process, last week work was revived on x86_64 parallel CPU bring-up for the Linux kernel to help in booting the kernel faster on larger core count desktops and servers. The results have been promising and over the past few days more test results have flowed in along with other positive commentary that will hopefully this time lead to the work ultimately getting upstreamed...

[Unstable Update] 2023-02-06 - GlibC updates

Monday 6th of February 2023 11:39:36 AM
This is more a short one to announce. Currently the toolchain has changed due to glibc updates, hence the kernels need to been rebuild to get dkms working again … :: Different sync package(s) in repository community x86_64 ------------------------------------------------------------------------------- PACKAGE testing unstable ------------------------------------------------------------------------------- gdu 5.21.1-2 5.22.0-1 netfilter-fullconenat r73.0cf3b48-267 r73.0cf3b48-268 python-pdm 2.4.0-1 2.4.3-1 python-pdm-pep517 1:1.0.6-1 1:1.1.1-1 telegram-desktop 4.5.3-1 4.6.0-1 zycore-c 1.4.1-2 1.4.1-3 zydis 4.0.0-2 4.0.0-3 :: Different sync package(s) in repository core x86_64 ------------------------------------------------------------------------------- PACKAGE testing unstable ------------------------------------------------------------------------------- binutils 2.40-2 2.40-4 debuginfod 0.188-2 0.188-3 elfutils 0.188-2 0.188-3 gcc 12.2.1-1 12.2.1-2 gcc-ada 12.2.1-1 12.2.1-2 gcc-d 12.2.1-1 12.2.1-2 gcc-fortran 12.2.1-1 12.2.1-2 gcc-go 12.2.1-1 12.2.1-2 gcc-libs 12.2.1-1 12.2.1-2 gcc-objc 12.2.1-1 12.2.1-2 glibc 2.36-7 2.37-2 lib32-gcc-libs 12.2.1-1 12.2.1-2 lib32-glibc 2.36-7 2.37-2 libelf 0.188-2 0.188-3 libgccjit 12.2.1-1 12.2.1-2 libtool 2.4.7+4+g1ec8fa28-1 2.4.7+4+g1ec8fa28-2 linux-api-headers 5.18.15-1 6.1.9-1 lto-dump 12.2.1-1 12.2.1-2 mpfr 4.2.0-2 4.2.0-3 :: Different sync package(s) in repository extra x86_64 ------------------------------------------------------------------------------- PACKAGE testing unstable ------------------------------------------------------------------------------- dejagnu 1.6.3-4 1.6.3-5 libgphoto2 2.5.30-1 2.5.30-2 libsysprof-capture 3.46.0-3 3.46.0-4 sysprof 3.46.0-3 3.46.0-4 valgrind 3.19.0-6 3.19.0-7 Additional Info Info about AUR packages (click for more details) Click to view the poll. Check if your mirror has already synced: Mirror-Check Service 2 posts - 2 participants Read full topic