Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Save more on your purchases! discount-offer-chevron-icon
Savings automatically calculated. No voucher code required.
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Newsletter Hub
Free Learning
Arrow right icon
timer SALE ENDS IN
0 Days
:
00 Hours
:
00 Minutes
:
00 Seconds

Tech News - Application Development

279 Articles
article-image-introducing-pyoxidizer-an-open-source-utility-for-producing-standalone-python-applications-written-in-rust
Bhagyashree R
26 Jun 2019
4 min read
Save for later

Introducing PyOxidizer, an open source utility for producing standalone Python applications, written in Rust

Bhagyashree R
26 Jun 2019
4 min read
On Monday, Gregory Szorc, a Developer Productivity Engineer at Airbnb, introduced PyOxidizer, a Python application packaging and distribution tool written in Rust. This tool is available for Windows, macOS, and Linux operating systems. Sharing his vision behind this tool, Szorc wrote in the announcement, “I want PyOxidizer to provide a Python application packaging and distribution experience that just works with a minimal cognitive effort from Python application maintainers.” https://twitter.com/indygreg/status/1143187250743668736 PyOxidizer aims to solve complex packaging and distribution problems so that developers can put their efforts into building applications instead of juggling with build systems and packaging tools. According to the GitHub README, “PyOxidizer is a collection of Rust crates that facilitate building libraries and binaries containing Python interpreters.” Its most visible component is the ‘pyoxidizer’ command line tool. With this tool, you can create new projects, add PyOxidizer to existing projects, produce binaries containing a Python interpreter, and various related functionality. How PyOxidizer is different from other Python application packaging/distribution tools PyOxidizer provides the following benefits over other Python application packaging/distribution tools: It works across all popular platforms, unlike many other tools that only target Windows or macOS. It works even if the executing system does not have Python installed. It does not have special system requirements like SquashFS, container runtimes, etc. Its startup performance is comparable to traditional Python execution. It supports single file executables with minimal or none system dependencies. Here are some of the features PyOxidizer comes with: Generates a standalone single executable file One of the most important features of PyOxidizer is that it can produce a single executable file that contains a fully-featured Python interpreter, its extensions, standard library, and your application's modules and resources. PyOxidizer embeds self-contained Python interpreters as a tool and software library by exposing its lower-level functionality. Serves as a bridge between Rust and Python The ‘Oxidizer’ part in PyOxidizer comes from Rust. Internally, it uses Rust to produce executables and manage the embedded Python interpreter and its operations. Along with solving the problem of packaging and distribution with Rust, PyOxidizer can also serve as a bridge between these two languages. This makes it possible to add a Python interpreter to any Rust project and vice versa. With PyOxidizer, you can bootstrap a new Rust project that contains an embedded version of Python and your application. “Initially, your project is a few lines of Rust that instantiates a Python interpreter and runs Python code. Over time, the functionality could be (re)written in Rust and your previously Python-only project could leverage Rust and its diverse ecosystem,” explained Szorc. The creator chose Rust for the run-time and build-time components because it is considered to be one of the superior systems programming languages and does not require considerable effort solving difficult problems like cross-compiling. He believes that implementing the embedding component in Rust also opens more opportunities to embed Python in Rust programs. “This is largely an unexplored area in the Python ecosystem and the author hopes that PyOxidizer plays a part in more people embedding Python in Rust,” he added. PyOxidizer executables are faster to start and import During the execution, binaries built with PyOxidizer does not have to do anything special like creating a temporary directory to run the Python interpreter. Everything is loaded directly from the memory without any explicit I/O operations. So, when a Python module is imported, its bytecode is loaded from a memory address in the executable using zero-copy. This results in making the executables produced by PyOxidizer faster to start and import. PyOxidizer is still in its early stages. Yesterday’s initial release is good at producing executables embedding Python. However, not much has been implemented yet to solve the distribution part of the problem. Some of the missing features that we can expect to come in the future are an official build environment, support for C extensions, more robust packaging support, easy distribution, and more. The creator encourages Python developers to try this tool and share feedback with him or file an issue on GitHub. You can also contribute to this project via Patreon or PayPal. Many users are excited to try this tool: https://twitter.com/kevindcon/status/1143750501592211456 https://twitter.com/acemarke/status/1143389113871040517 Read the announcement made by Szorc to know more in detail. Python 3.8 beta 1 is now ready for you to test PyPI announces 2FA for securing Python package downloads Matplotlib 3.1 releases with Python 3.6+ support, secondary axis support, and more
Read more
  • 0
  • 0
  • 21798

article-image-devops-platform-for-coding-gitlab-reached-more-than-double-valuation-of-2-75-billion-than-its-last-funding-and-way-ahead-of-its-ipo-in-2020
Fatema Patrawala
19 Sep 2019
4 min read
Save for later

DevOps platform for coding, GitLab reached more than double valuation of $2.75 billion than its last funding and way ahead of its IPO in 2020

Fatema Patrawala
19 Sep 2019
4 min read
Yesterday, GitLab, a San Francisco based start-up, raised $268 million in a Series E funding round valuing the company at $2.75 billion, more than double of its last valuation. In the Series D round funding of $100 million the company was valued at $1.1 billion; and with today’s announcement, the valuation has more than doubled in less than a year. GitLab provides a DevOps platform for developing and collaborating on code and offers a single application for companies to draft, develop and release code. The product is used by companies like Delta Air Lines Inc., Ticketmaster Entertainment Inc. and Goldman Sachs Group Inc etc. The Series E funding round was led by investors including Adage Capital Management, Alkeon Capital, Altimeter Capital, Capital Group, Coatue Management, D1 Capital Partners, Franklin Templeton, Light Street Capital, Tiger Management Corp. and Two Sigma Investments. GitLab plans to go public in November 2020 According to Forbes, GitLab has already set November 18, 2020 as the date for going public. The company seems to be primed and ready for the eventual IPO. As for the $268 million, it gives the company considerable time ahead of the planned event and also gives the flexibility to choose how to take the company public. “One other consideration is that there are two options to go public. You can do an IPO or direct listing. We wanted to preserve the optionality of doing a direct listing next year. So if we do a direct listing, we’re not going to raise any additional money, and we wanted to make sure that this is enough in that case,” Sid Sijbrandij, Gitlab co-founder and CEO explained in an interview for TechCrunch. He further adds, that the new funds will be used to add monitoring and security to GitLab’s offering, and to increase the company’s staff to more than 1,000 employees this year from 400 employee strength currently. GitLab is able to add workers at a rapid rate, since it has an all-remote workforce. GitLab wants to be independent and chooses transparency for community Sijbrandij says that the company made a deliberate decision to be transparent early on. Being based on an open-source project, it’s sometimes tricky to make the transition to a commercial company, and sometimes that has a negative impact on the community and the number of contributions. Transparency was a way to combat that, and it seems to be working. He reports that the community contributes 200 improvements to the GitLab open-source products every month, and that’s double the amount of just a year ago, so the community is still highly active. He did not ignore the fact that Microsoft acquired GitHub last year for $7.5 billion. And GitLab is a similar kind of company that helps developers manage and distribute code in a DevOps environment. He claims in spite of that eye-popping number, his goal is to remain an independent company and take this through to the next phase. “Our ambition is to stay an independent company. And that’s why we put out the ambition early to become a listed company. That’s not totally in our control as the majority of the company is owned by investors, but as long as we’re more positive about the future than the people around us, I think we can we have a shot at not getting acquired,” he said. Community is happy with GitLab’s products and services Overall the community is happy with this news and GitLab’s products and services. One of the comments on Hacker News reads, “Congrats, GitLab team. Way to build an impressive business. When anybody tells you there are rules to venture capital — like it’s impossible to take on massive incumbents that have network effects — ignore them. The GitLab team is doing something phenomenal here. Enjoy your success! You’ve earned it.” Another user comments, “We’ve been using Gitlab for 4 years now. What got us initially was the free private repos before github had that. We are now a paying customer. Their integrated CICD is amazing. It works perfectly for all our needs and integrates really easily with AWS and GCP. Also their customer service is really damn good. If I ever have an issue, it’s dealt with so fast and with so much detail. Honestly one of the best customer service I’ve experienced. Their product is feature rich, priced right and is easy. I’m amazed at how the operate. Kudos to the team” Other interesting news in programming Microsoft open-sources its C++ Standard Library (STL) used by MSVC tool-chain and Visual Studio Linux 5.3 releases with support for AMD Navi GPUs, Zhaoxin x86 CPUs and power usage improvements NVIM v0.4.0 releases with new API functions, Lua library, UI events and more!
Read more
  • 0
  • 0
  • 21426

article-image-openbsd-6-6-comes-with-gcc-disabled-in-base-for-armv7-and-i386-smp-improvements-and-more
Bhagyashree R
18 Oct 2019
3 min read
Save for later

OpenBSD 6.6 comes with GCC disabled in base for ARMv7 and i386, SMP Improvements, and more

Bhagyashree R
18 Oct 2019
3 min read
Yesterday, the team behind OpenBSD, a Unix-like operating system, announced the release of OpenBSD 6.6. This release has GNU Compiler Collection (GCC) disabled in its base packages for i386 and ARMv7 and expanded LLVM Clang platform support. OpenBSD 6.6 also features various SMP improvements, improved Linux compatibility with ACPI interfaces, a number of new hardware drivers, and more. It ships with OpenSSH 8.1, LibreSSL 3.0.2, OpenSMTPD 6.6, and other updated packages. Read also: OpenSSH code gets an update to protect against side-channel attacks Key updates in OpenBSD 6.6 Unlocked system calls OpenBSD 6.6 comes with unlocked ‘getrlimit’ and ‘setrlimit’ system calls. These are used for controlling the maximum system resource consumption. There are also unlocked read and write system calls for reading input and writing output respectively. Improved hardware support OpenBSD 6.6 comes with Linux compatible ACPI interfaces. Also, the ACPI support is enabled in ‘radeon’ and ‘amdgpu’. Time Stamp Counter (TSC) is re-enabled as the default AMD64 time source and TSC synchronization is added for multiprocessor machines. This release supports the cryptographic coprocessor found on newer AMD Ryzen CPUs/APUs. IEEE 802.11 wireless stack improvements The ifconfig ‘nwflag’ is now repaired. A new stayauth ‘nwflag’ is added, which you can set to ignore deauth frames to prevent your system from a spoofing attack. Support for 802.11n Tx aggregation is added to net80211 and the ‘iwn’ driver. Starting with OpenBSD 6.6, all wireless drives submit a batch of received packets to the network stack during one interrupt, instead of submitting them individually. Security improvements The unveil command is updated to improve application behavior when encountering hidden filesystem paths. OpenBSD 6.6 has improved mitigations against a number of vulnerabilities including Spectre side-channel vulnerability in Intel CPUs and Intel's Microarchitectural Data Sampling vulnerability. This release introduces 'malloc_conceal' and 'calloc_conceal', which return the memory in pages marked ‘MAP_CONCEAL’ and call ‘freezero’ on ‘free’. Read also: Seven new Spectre and Meltdown attacks found In a discussion on Hacker News, many users expressed their excitement. A user commented, “Just keeps getting better and better every release. I wish they would add an easy encryption option in the installer. You can enable full-disk encryption, but you have to mess with the bioctl settings, which potentially scares off new users.” A few users also had some doubt that why this release has U2F support and Bluetooth disabled for security. A user explained, “I'm not sure why U2F would be "disabled for security". I guess it's just that nobody has implemented all the required things. For the USB tokens, you need userspace USB HID access and hotplug notifications. I did that in Firefox for FreeBSD.” These were some of the updates in OpenBSD 6.6. Check out the official announcement to know more. OpenBSD 6.4 released OpenSSH code gets an update to protect against side-channel attacks OpenSSH 8.0 released; addresses SCP vulnerability and new SSH additions  
Read more
  • 0
  • 0
  • 21208

article-image-net-core-2-0-reaches-end-of-life-no-longer-supported-by-microsoft
Prasad Ramesh
04 Oct 2018
2 min read
Save for later

.NET Core 2.0 reaches end of life, no longer supported by Microsoft

Prasad Ramesh
04 Oct 2018
2 min read
.NET Core 2.0 was released mid August 2017. It has now reached end of life (EOL) and will no longer be supported by Microsoft. .NET Core 2.0 EOL .NET Core 2.1 was released towards the end of May 2018 and .NET Core 2.0 reached EOL on October 1. This was supposed to happen on September 1 but was pushed by a month since users experienced issues in upgrading to the newer version. .NET Core 2.1 is a long-term support (LTS) release and should be supported till at least August 2021. It is recommended to upgrade to and use .NET Core 2.1 for your projects. There are no major changes in the newer version. .NET Core 2.0 is no longer supported and updates won’t be provided. The installers, zips and Docker images of .NET Core 2.0 will still remain available, but they won’t be supported. Downloads for 2.0 will still be accessible via the Download Archives. However, .NET Core 2.0 is removed from the microsoft/dotnet repository README file. All the existing images will still be available in that repository. Microsoft’s support policy The ‘LTS’ releases contain stabilized features and components. They require fewer updates over their longer support release lifetime. The LTS releases are a good choice for applications that developers do not intend to update very often. The ‘current’ releases include features that are new and may undergo changes in the future based on feedback/issues. They give access to the latest features and improvements and hence are a good choice for applications in active development. Upgrades to newer .NET Core releases is required more frequently to stay in support. Some of the new features in .NET Core 2.1 include performance improvements, long term support, Brotli compression, and new cryptography APIs. To migrate from .NET Core 2.0 to .NET Core 2.1, visit the Microsoft website. You can read the official announcement on GitHub. Note: article amended 08.10.2018 - .NET Core 2.0 reached EOL on October 1, not .NET Core 2.1. The installers, zips and Docker images will still remain available but won't be supported, not unsupported. .NET announcements: Preview 2 of .NET Core 2.2 and Entity Framework Core 2.2, C# 7.3, and ML.NET 0.5 Microsoft’s .NET Core 2.1 now powers Bing.com Use App Metrics to analyze HTTP traffic, errors & network performance of a .NET Core app [Tutorial]
Read more
  • 0
  • 4
  • 21202

article-image-wireguard-to-be-merged-with-linux-net-next-tree-and-will-be-available-by-default-in-linux-5-6
Savia Lobo
12 Dec 2019
3 min read
Save for later

WireGuard to be merged with Linux net-next tree and will be available by default in Linux 5.6

Savia Lobo
12 Dec 2019
3 min read
On December 9, WireGuard announced that its secure VPN tunnel kernel code will soon be included in Linux net-next tree. This indicates, “WireGuard will finally reach the mainline kernel with the Linux 5.6 cycle kicking off in late January or early February!”, reports Phoronix. WireGuard is a layer 3 secure networking tunnel made specifically for the kernel, that aims to be much simpler and easier to audit than IPsec. On December 8, Jason Donenfeld, WireGuard’s lead developer sent out patches for the net-next v2 WireGuard. “David Miller has already pulled in WireGuard as the first new feature in net-next that is destined for Linux 5.6 now that the 5.5 merge window is over,” the email thread mentions. While WireGuard was initiated as a Linux project, its Windows, macOS, BSD, iOS, and Android versions are already available. The reason behind the delay for Linux was that Donenfeld disliked Linux’s built-in cryptographic subsystem citing its API is too complex and difficult. Donenfeld had plans to introduce a new cryptographic subsystem — his own Zinc library. However, this didn’t go down well with several developers as they thought that rewriting the cryptographic subsystem was a waste of time. Fortunately for Donenfeld, Linus Torvalds was on his side. Torvalds stated, “I’m 1000% with Jason on this. The crypto/model is hard to use, inefficient, and completely pointless when you know what your cipher or hash algorithm is, and your CPU just does it well directly.” Finally, Donenfeld compromised saying, "WireGuard will get ported to the existing crypto API. So it's probably better that we just fully embrace it, and afterward work evolutionarily to get Zinc into Linux piecemeal." Hence a few Zine elements have been imported into the legacy crypto code in the next Linux 5.5 kernel. WireGuard would become the new standard for Linux VPNs This laid the foundation for WireGuard to finally ship in Linux early next year. WireGuard works by securely encapsulates IP packets over UDP. It's authentication and interface design has more to do with Secure Shell (SSH) than other VPNs. You simply configure the WireGuard interface with your private key and your peers' public keys, and you're ready to securely talk. After the arrival, WireGuard VPN can be expected to become the new standard for Linux VPNs with its key features, namely, tiny code-size, high-speed cryptographic primitives, and in-kernel design. With being super-fast, WireGuard for Linux would be secure too as it supports state-of-the-art cryptography technologies such as the Noise protocol framework, Curve25519, BLAKE2, SipHash24, ChaCha20, Poly1305, and HKD. Donenfeld in the email thread writes, “This is big news and very exciting. Thanks to all the developers, contributors, users, advisers, and mailing list interlocutors who have helped to make this happen. In the coming hours and days, I'll be sending followups on next steps.” ArsTechnica reports, “Although highly speculative, it's also possible that WireGuard could land in-kernel on Ubuntu 20.04 even without the 5.6 kernel—WireGuard founder Jason Donenfeld offered to do the work backporting WireGuard into earlier Ubuntu kernels directly. Donenfeld also stated today that a 1.0 WireGuard release is ‘on the horizon’." To know more about this news in detail, read the official email thread. WireGuard launches an official MacOS app Researchers find a new Linux vulnerability that allows attackers to sniff or hijack VPN connections. NCSC investigates several vulnerabilities in VPN products from Pulse secure, Palo Alto and Fortinet
Read more
  • 0
  • 0
  • 21134

article-image-introducing-swiftwasm-a-tool-for-compiling-swift-to-webassembly
Bhagyashree R
13 May 2019
2 min read
Save for later

Introducing SwiftWasm, a tool for compiling Swift to WebAssembly

Bhagyashree R
13 May 2019
2 min read
The attempts of porting Swift to WebAssembly has been going on for very long, and finally, a team of developers has come up with SwiftWasm, which was released last week. With this tool, you will now be able to run your Swift code on the web by compiling it to WebAseembly. https://twitter.com/swiftwasm/status/1127324144121536512 The SwiftWasm tool is built on top of the WASI SDK, which is a WASI-enabled C/C++ toolchain. This makes the WebAssembly executables generated by SwiftWasm work on both browsers and standalone WebAssembly runtimes such as Wasmtime, Fastly’s Lucet, or any other WASI-compatible WebAssembly runtime. How you can work with SwiftWasm? While macOS does not need any dependencies to be installed, some dependencies need to be installed on Ubuntu and Windows: On Ubuntu install ‘libatomic1’: sudo apt-get install libatomic1 On Windows: First Install the Windows Subsystem for Linux, and then install the libatomic1 library. The next step is to compile SwiftWasm by running the following commands: ./swiftwasm example/hello.swift hello.wasm To run the resulting ‘hello.wasm’ file, go to the SwiftWasm polyfill and upload the file. You will see the output in the textbox. This polyfill supports Firefox 66, Chrome 74, and Safari 12.1. The news of having a tool for running Swift on the web has got many developers excited. https://twitter.com/pvieito/status/1127620197668487169 https://twitter.com/johannesweiss/status/1126913408455053312 https://twitter.com/jedisct1/status/1126909145926569986 The project is still work-in-progress and thus has some limitations. Currently, only the Swift ‘stdlib’ is compiled and other libraries such as Foundation or SwiftPM are not included. Few functions such as ‘Optional.Map’ does not work because of the calling convention differences between throwing and non-throwing closures. If you want to contribute to this project, check out its pull request on Swift’s GitHub repository to know more about its current status. You can try SwiftWasm on its official website. Swift is improving the UI of its generics model with the “reverse generics” system Swift 5 for Xcode 10.2 is here! Implementing Dependency Injection in Swift [Tutorial]
Read more
  • 0
  • 0
  • 21062
Unlock access to the largest independent learning library in Tech for FREE!
Get unlimited access to 7500+ expert-authored eBooks and video courses covering every tech area you can think of.
Renews at $19.99/month. Cancel anytime
article-image-racket-7-5-releases-with-relicensing-to-apache-mit-standard-json-mime-dark-mode-interface-and-more
Fatema Patrawala
22 Nov 2019
3 min read
Save for later

Racket 7.5 releases with relicensing to Apache/MIT, standard JSON MIME, dark mode interface and more

Fatema Patrawala
22 Nov 2019
3 min read
On Tuesday, Racket, a general-purpose programming language announced Racket 7.5. Racket is based on the Scheme dialect of Lisp programming language and is designed to be a platform for programming language design and implementation. Racket is also used to refer to the family of Racket programming languages and the set of tools supporting development on and with Racket. Key features in Racket 7.5 This new release will be distributed under a new and less-restrictive license, either the Apache 2.0 or the MIT license Racket CS will remain in beta for the v7.5, but the compatibility and performance continue to improve. It is expected to be ready for production use by the next release In this release of Racket 7.5 the Web Server provides a standard JSON MIME type, including a response/jsexpr form for HTTP responses bearing JSON In this release GNU MPFR operations run about 3x faster Typed Racket supports definitions of new struct type properties and type checks uses existing struct type properties in struct definitions. Previously, these were ignored by the type checker, so type errors may have been hidden The performance bug in v7.4’s big bang has been repaired DrRacket supports Dark Mode for interface elements. With this release plot can display parametric 3d surfaces and redex supports modeless judgment forms Additionally with the above changes, in the Racket 7.5 MacOS Catalina 10.15 includes a new requirement that executables be “notarized”, to give Apple the ability to prevent certain kinds of malware. In this release, all of the disk images (.dmg’s) are notarized, along with the applications that they contain (.app’s). Many users may not notice any difference, but two groups of Catalina users will be affected; First those who use the “racket” binary directly, and second, those that download the .tgz bundles. In both cases, the operating system is likely to inform that the given executable is not trusted, or that the developer can’t be verified. Fortunately, both groups of users are probably also running commands in a shell, hence the solution for both groups will be the same that is to disable the quarantine flag using the xattr command, for example, xattr -d com.apple.quarantine /path/to/racket. To know more about this news, check out the official announcement on the Racket page. Matthew Flatt’s proposal to change Racket’s s-expressions based syntax to infix representation creates a stir in the community Racket 7.3 releases with improved Racket-on-Chez, refactored IO system, and more Racket 7.2, a descendent of Scheme and Lisp, is now out! Racket v7.0 is out with overhauled internals, updates to DrRacket, TypedRacket among others  
Read more
  • 0
  • 0
  • 20990

article-image-nvidia-open-sources-its-material-definition-language-mdl-sdk
Prasad Ramesh
16 Aug 2018
3 min read
Save for later

NVIDIA open sources its material definition language, MDL SDK

Prasad Ramesh
16 Aug 2018
3 min read
“Security, customizability, flexibility and cost are a few of the benefits of open-source software for developers. They’ll get all these and more from NVIDIA’s Material Definition Language software development kit.” —NVIDIA Blog. The material definition language (MDL) is a programming language used to define and render physical materials. This includes the creation of a wide range of physical materials such as woods, fabrics, translucent plastics and more. It is a set of tools integrating the precise look and feel of real-world materials into rendering applications. It gives users the freedom to share these materials between applications that support them. Now users can move a library of these materials between applications without worrying about them losing their appearance. This will allow developers to focus on building their applications. Allegorithmic had already built an entire MDL authoring tool, but with NVIDIA making the MDL SDK open source, developers get a deeper unrestricted access to the entire spec. The Blog states that Unreal Studio 4.20 now offers native support for MDL. “Being able to use a single material definition, like NVIDIA’s MDL, across multiple applications and render engines is a huge benefit to the end-user,” said Ken Pimentel, senior product manager of the Enterprise team at Epic Games. “Now that we’ve added MDL support to Unreal Studio, our enterprise customers can see their material representations converted to real time in Unreal Engine without baking every parameter. This means their creative intent can be carried to new forms of expression.” The MDL SDK API is C++ based and used for integration and customization tasks. It can be loaded dynamically and linked to visualization applications. The API also allows applications to load MDL modules, and analyze and understand the structure of a material. Therefore it can build a UI for editing materials then rendering the results. Some of the features in MDL SDK include: Can be used on GPU as well as CPU Database view on the imported MDL package space MDL editing C++ component-based API, and plugin architecture for extensibility MDL SDK supports Windows (only 64-bit), Linux, and macOS. To know more, visit the NVIDIA website and to get started here is the GitHub repository. Nvidia unveils a new Turing architecture: “The world’s first ray tracing GPU” Nvidia and AI researchers create AI agent Noise2Noise that can denoise images Nvidia GPUs offer Kubernetes for accelerated deployments of Artificial Intelligence workloads
Read more
  • 0
  • 0
  • 20968

article-image-electron-7-0-releases-in-beta-with-windows-on-arm-64-bit-faster-ipc-methods-nativetheme-api-and-more
Fatema Patrawala
24 Oct 2019
3 min read
Save for later

Electron 7.0 releases in beta with Windows on Arm 64 bit, faster IPC methods, nativetheme API and more

Fatema Patrawala
24 Oct 2019
3 min read
Last week the team at Electron announced the release of Electron 7.0 in beta. It includes upgrades to Chromium 78, V8 7.8, and Node.js 12.8.1. The team has added a Window on Arm 64 release, faster IPC methods, a new nativeTheme API, and much more. This release is published to npm under the beta tag and can be installed via npm install electron@beta, or npm i electron@7.0.0-beta.7. It is packed with upgrades, fixes, and new features. Notable changes in Electron 7.0 There are stack upgrades in this release, Electron 7.0 will be compatible on Chromium 78, V8 7.8 and Node.js 12.8.1. In this release they have added Windows on Arm (64 bit). The team has added ipcRenderer.invoke() and ipcMain.handle() for asynchronous request/response-style IPC. These are strongly recommended over the remote module. They have added nativeTheme API to read and respond to changes in the OS's theme and color scheme. In this release they have switched to a new TypeScript Definitions generator, which generates more precise definitions files (d.ts) from C# model classes to build strongly typed web application where the server- and client-side models are in sync. Earlier Electron used Doc Linter and Doc Parser but it had a few issues and hence shifted to TypeScript to make definition files better without losing any information on docs. Other breaking changes The team has removed deprecated APIs in this release: Callback-based versions of functions that now use Promises. Tray.setHighlightMode() (macOS). app.enableMixedSandbox() app.getApplicationMenu(), app.setApplicationMenu(), powerMonitor.querySystemIdleState(), powerMonitor.querySystemIdleTime(), webFrame.setIsolatedWorldContentSecurityPolicy(), webFrame.setIsolatedWorldHumanReadableName(), webFrame.setIsolatedWorldSecurityOrigin() Session.clearAuthCache() no longer allows filtering the cleared cache entries. Native interfaces on macOS (menus, dialogs, etc.) now automatically match the dark mode setting on the user's machine. The team has updated the electron module to use @electron/get. Node 8 is the minimum supported node version in this release. The electron.asar file no longer exists. Any packaging scripts that depend on its existence should be updated by the developers. Additionally the team announced that Electron 4.x.y has reached end-of-support as per the project's support policy. Developers and applications are encouraged to upgrade to a newer version of Electron. To know more about this release, check out the Electron 7.0 GitHub page and the official blog post. Electron 6.0 releases with improved Promise support, native Touch ID authentication support, and more Electron 5.0 ships with new versions of Chromium, V8, and Node.js The Electron team publicly shares the release timeline for Electron 5.0
Read more
  • 0
  • 0
  • 20887

article-image-electron-6-0-releases-with-improved-promise-support-native-touch-id-authentication-support-and-more
Bhagyashree R
01 Aug 2019
3 min read
Save for later

Electron 6.0 releases with improved Promise support, native Touch ID authentication support, and more

Bhagyashree R
01 Aug 2019
3 min read
On Tuesday, the team behind Electron, the web framework for building desktop apps, announced the release of Electron 6.0. It comes with further improvement in the ‘Promise’ support, native Touch ID authentication support for macOS, native emoji and color picker methods, and more. This release is upgraded to Chrome 76, Node.js 12.4.0, and V8 7.6. https://twitter.com/electronjs/status/1156273653635407872 Promisification of functions continue Starting from Electron 5.0, the team introduced a process called “promisification” in which callback-based functions are converted to return ‘Promises’. In Electron 6.0, the team has converted 26 functions to return Promises and also supported callback-based invocation. Among these “promisified” functions are ‘contentTracing.getCategories()’, ‘cookies.flushStore()’, ‘dialog.showCertificateTrustDialog()’, and more. Three new variants of the Helper app The hardened runtime was introduced to prevent exploits like code injection, DLL hijacking, and process memory space tampering. However, to serve the purpose it does restricts things like writable-executable memory and loading code signed by a different Team ID.  If your app relies on such functionalities, you can add an entitlement to disable individual protection. To enable a hardened runtime in an Electron app, special code signing entitlements were granted to Electron Helper. Starting from Electron 6.0, three new variants of the Helper app are added to keep these granted entitlements scoped to the process types that require them. These are ‘Electron Helper (Renderer).app)’, ‘(Electron Helper (GPU).app)’, and ‘(Electron Helper (Plugin).app)’. Developers using ‘electron-osx-sign’ to codesign their Electron app, do not have to make any changes to their build logic. But if you are using custom scripts instead, then you will need to ensure that the three Helper apps are correctly codesigned. To correctly package your application with these new helpers, use ‘electron-packager@14.0.4’ or higher. Miscellaneous changes to Electron 6.0 Electron 6.0 brings native Touch ID authentication support for macOS. There are now native emoji and color picker methods for Windows and macOS. The ‘chrome.runtime.getManifest’ API for Chrome extensions is added that returns details about the app or extension from the manifest. The ‘<webview>.getWebContentsId()’ method is added that allows getting the WebContents ID of WebViews when the remote module is disabled. Support is added for the Chrome extension content script option ‘all_frames’. This option allows an extension to specify whether JS and CSS files should be injected into all frames or only into the topmost frame in a tab. With Electron 6.0, the team has laid out the groundwork for a future requirement, which says that all native Node modules loaded in the renderer process will be either N-API or Context Aware. This is done for faster performance, better security, and reduced maintenance workload. Along with the release announcement, the team also announced the end of life of Electron 3.x.y and has recommended upgrading to a newer version of Electron. To know all the new features in Electron 6.0, check out the official announcement. Electron 5.0 ships with new versions of Chromium, V8, and Node.js The Electron team publicly shares the release timeline for Electron 5.0 How to create a desktop application with Electron [Tutorial]
Read more
  • 0
  • 0
  • 20865
article-image-net-framework-api-porting-project-concludes-with-net-core-3-0
Savia Lobo
17 Oct 2019
3 min read
Save for later

.NET Framework API Porting Project concludes with .NET Core 3.0

Savia Lobo
17 Oct 2019
3 min read
Two days ago, Immo Landwerth, a program manager on the .NET team announced that the community is concluding the .NET Framework API Porting project. They also plan to release more of the .NET Framework codebase under the MIT license on GitHub to allow the community to create OSS projects for technologies that will not be brought to .NET Core. For example, there already are community projects for CoreWF and CoreWCF. https://twitter.com/shanselman/status/1184214679779864576 In May, this year, Microsoft announced that the future of .NET will be based on .NET Core. At Build 2019, Scott Hunter stated that AppDomains, remoting, Web Forms, WCF server, and Windows Workflow won’t be ported to .NET Core. “With .NET Core 3.0, we’re at the point where we’ve ported all technologies that are required for modern workloads, be it desktop apps, mobile apps, console apps, web sites, or cloud services,” Landwerth writes. .NET Core 3.0 released last month includes added WPF and WinForms, which increased the number of .NET Framework APIs ported to .NET Core to over 120k, which is more than half of all .NET Framework APIs. Also, about 62K APIs to .NET Core that doesn’t exist in the .NET Framework. On comparing the total number of APIs, .NET Core has about 80% of the API surface of .NET Framework. “Since we generally no longer plan to bring existing technologies from .NET Framework to .NET Core we’ll be closing all issues that are labeled with port-to-core,” Landwerth further mentions. Post this announcement on GitHub, a lot of GitHub users enquired more about this change in the .NET community. A user asked, “Is CSharpCodeProvider ever going to happen in Core? The CodeDom API arrived somewhere in the 2.x timeframe, but it's a runtime fail even under 3.0 - are we going to need to re-write for some kind of explicitly Roslyn scripting?” To this, Landwerth replied, “CSharpCodeProvider is supported on .NET Core, but only the portions that deal with CodeDOM creation. You can't compile because this would require a compiler and the .NET Core runtime doesn't include a compiler (i.e. Roslyn). However, we might be able to do some gymnastics, like reflection, where the app can pull that in. Still tracked under #12180.” https://twitter.com/terrajobst/status/1183832593197744129 To know more about this announcement in detail, read the official GitHub post. .NET 5 arriving in 2020! Docker announces collaboration with Microsoft’s .NET at DockerCon 2019 .NET Core 3.0 is now available with C# 8, F# 4.7, ASP.NET Core 3.0 and EF 6.3
Read more
  • 0
  • 0
  • 20750

article-image-microsoft-build-2019-introducing-windows-terminal-application-packed-with-multiple-tab-opening-improved-text-and-more
Amrata Joshi
07 May 2019
2 min read
Save for later

Microsoft Build 2019: Introducing Windows Terminal, application packed with multiple tab opening, improved text and more

Amrata Joshi
07 May 2019
2 min read
Yesterday, at the Microsoft Build 2019, the team at Microsoft announced Windows Terminal, a new terminal application for users of command-line tools and shells like PowerShell, Command Prompt, and WSL. This terminal will be delivered via the Microsoft Store in Windows 10 and will be regularly updated. Key features of Windows Terminal Multiple tabs Windows Terminal comes with multiple tab support so users will now be able to open any number of tabs, each connected to a command-line shell or app of their choice. E.g. PowerShell, Ubuntu on WSL, Command Prompt, a Raspberry Pi via SSH, etc. Text Windows terminal uses a GPU accelerated DirectWrite/DirectX-based text rendering engine so that it displays text characters, glyphs, and symbols present within fonts on the PC. In addition, it also includes emoji, powerline symbols, CJK ideograms, icons, programming ligatures, etc. It can also render text much faster as compared to the previously used engines. Users now have the option of using their own new font. Settings and configurability Windows Terminal comes with many settings and configuration options that manage Terminal’s appearance and each of the shells/profiles that users open as new tabs. The settings are stored in a structured text file so that it makes it easy for users and/or tools to configure. With the terminal’s configuration mechanism, users will be able to create multiple “profiles” for each shell/app/tool. And these profiles can have their own combination of color themes, font styles and sizes, background blur/transparency levels, etc so that users can now create their own custom-styled Terminal. Windows Console The team further announced that they are open sourcing Windows Console which hosts the command-line infrastructure in Windows and provides the traditional Console UX. The primary goal of the console is preserving backward compatibility with existing command-line tools, scripts, etc. To know more about this news, check out Microsoft’s blog post. Microsoft introduces Remote Development extensions to make remote development easier on VS Code Docker announces collaboration with Microsoft’s .NET at DockerCon 2019 Microsoft and GitHub employees come together to stand with the 996.ICU repository    
Read more
  • 0
  • 0
  • 20468

article-image-elementary-os-5-1-hera-releases-with-flatpak-native-support-several-accessibility-improvements-and-more
Bhagyashree R
09 Dec 2019
3 min read
Save for later

elementary OS 5.1 Hera releases with Flatpak native support, several accessibility improvements, and more

Bhagyashree R
09 Dec 2019
3 min read
Last week, the CEO and CXO of elementary OS, Cassidy James Blaede announced the release of elementary OS 5.1, code named ‘Hera’. elementary OS is an Ubuntu-based desktop distribution, which promises to be a “fast, open, and privacy-respecting” replacement to macOS and Windows.  Building upon the solid foundations laid out by its predecessor Juno, Hera brings several new features including native support for Flatpak, a faster AppCentre storefront, accessibility features, among other updates. Key updates in elementary OS 5.1 Hera Brand new greeter and onboarding In elementary OS 5.1 Hera, the greeter and onboarding have seen major changes in order to give users an improved first-run experience. In addition to looking better, the redesigned greeter addresses some of the key reported issues including keyboard focus issues, HiDPI issues, and better localization. Hera also ships with a new Onboarding app that gives you a quick introduction to key features and also takes care of common first-run tasks like managing privacy settings. Native Flatpak support and AppCenter updates elementary OS 5.1 Hera comes with native support for Flatpack, an application sandboxing and distribution framework. It enables developers to create one application and distribute it to different Linux desktop distributions.  Hera includes a new core elementary OS utility called Sideload that allows users to sideload Flatpak apps. Any updates to the sideloaded apps will appear in AppCenter and apps from any user-added Flatpak remotes will show up in AppCenter as uncurated apps. Along with the Flatpak support, Blaede shared that it is now “up to 10× faster in Hera, loading the homepage and featured apps blazingly fast.” Accessibility improvements A bunch of accessibility features has landed in elementary OS 5.1 Hera. System Settings are now more accessible to all users. Discoverability of performance and keyboard shortcut has been improved. Sound settings has a new approach to handling external devices and there is a “Flash screen” option for event alerts to better manage whether alerts are audible, visual, both, or neither. The Mouse & Touchpad settings in elementary OS 5.1 Hera are now organized into sections based on different behavior. Several accessibility settings like long-press secondary click, reveal pointer, double-click speed, and control pointer using keypad have been exposed. Also, the touchpad settings now has an “Ignore when mouse is connected” toggle. Many developers have already started trying out this release. A Hacker News user shared their first impressions on a discussion regarding this release, “I installed this on my XPS 13 this morning, and it's really nice. It has a lot of overall polish that most DE's are missing, it looks and feels cohesive. It installed without any issues, and I had no problem with my Ubuntu-leaning dotfiles. I will probably keep this for the near future, it's very pleasant.” These were some of the updates in elementary OS 5.1 Hera. Check out the official announcement to know more about this release. Redox OS will soon permanently run rustc, the compiler for the Rust programming language, says Redox creator Jeremy Soller Nate Chamberlain talks about the Microsoft Enterprise Mobility and Security suite and becoming M365 certified Microsoft technology evangelist Matthew Weston on how Microsoft PowerApps is democratizing app development [Interview]
Read more
  • 0
  • 0
  • 20371
article-image-fastly-open-sources-lucet-a-native-webassembly-compiler-and-runtime
Bhagyashree R
29 Mar 2019
2 min read
Save for later

Fastly open sources Lucet, a native WebAssembly compiler and runtime

Bhagyashree R
29 Mar 2019
2 min read
Yesterday, Fastly, a US-based cloud computing service provider, open-sourced its native WebAssembly compiler and runtime, Lucet. Lucet is built on top of Cranelift, Mozilla’s low-level retargetable code generator. It already powers Fastly’s Terrarium project, their experimental platform for edge computation using WebAssembly, and now it is coming to their edge cloud platform as well. How does Lucet work? Lucet delegates the responsibility of executing WebAssembly programs into two components: compiler and runtime. The compiler compiles WebAssembly modules to native code and the runtime manages resources and traps runtime faults. As it uses ahead-of-time compilation strategy, it simplifies the design and overhead of the runtime compared to just-in-time (JIT) compilation that browser engines use. What are its advantages? Faster and safer execution of WebAssembly programs WebAssembly allows web browsers to safely execute programs with near-native performance. It is supported by some of the most commonly used browsers including Google, Mozilla, and Safari. With Lucet, Fastly aims to take WebAssembly “beyond the browser” by providing users a platform for faster and safer execution of programs on Fastly’s edge cloud. More languages to choose from Since WebAssembly is supported by an impressive list of programming languages including Rust, TypeScript, C, and C++, Lucet users will be able to work with the language they prefer. They do not have to be restricted to Fastly’s Varnish Configuration Language (VCL). Simultaneous execution of programs The Lucet compiler and runtime ensure that each WebAssembly program is allocated its own resources. This enables Fastly’s edge cloud to simultaneously execute a large number of WebAssembly programs without compromising on security. Supports WebAssembly System Interface (WASI) Lucet supports WASI, an API that provides access to various operating-system-like features. These include files and filesystems, Berkeley sockets, clocks, and random numbers. At the moment, Lucet supports running WebAssembly programs written in C, Rust, and AssemblyScript and its runtime only support x86-64 based Linux systems. To read the official announcement, visit Fastly’s official website. Introducing CT-Wasm, a type-driven extension to WebAssembly for secure, in-browser cryptography Creating and loading a WebAssembly module with Emscripten’s glue code [Tutorial] The elements of WebAssembly – Wat and Wasm, explained [Tutorial]
Read more
  • 0
  • 0
  • 20343

article-image-ubuntu-19-10-releases-with-microk8s-add-ons-gnome-3-34-zfs-on-root-nvidia-specific-improvements-and-much-more
Vincy Davis
18 Oct 2019
4 min read
Save for later

Ubuntu 19.10 releases with MicroK8s add-ons, GNOME 3.34, ZFS on root, NVIDIA-specific improvements, and much more!

Vincy Davis
18 Oct 2019
4 min read
Yesterday, Canonical announced the release of Ubuntu 19.10 which is the fastest Ubuntu release with significant performance improvements to accelerate developer productivity in AI/ML. This release brings enhanced edge computing capabilities with the addition of strict confinement to MicroK8s, which will safeguard the complete isolation and presents a secured production-grade Kubernetes environment. This allows MicroK8s add-ons like Istio, Knative, CoreDNS, Prometheus, and Jaeger to be deployed securely at the edge with a single command. Ubuntu 19.10 also delivers other features like NVIDIA drivers which are embedded in the ISO image to improve the performance of gamers and AI/ML users. The CEO of Canonical, Mark Shuttleworth says, “With the 19.10 release, Ubuntu continues to deliver strong support, security and superior economics to enterprises, developers and the wider community.” The Ubuntu team has notified users that Ubuntu 19.10 will be only supported for 9 months, until July 2020. Users are also advised to use Ubuntu 18.04 for Long Term Support. What’s new in Ubuntu 19.10? Updated Packages Linux kernel: The new release is based on the Linux 5.3 series and will support AMD Navi GPUs, ARM SoCs, ARM Komeda display, and Intel speed select on Xeon servers. In order to improve the boot speed, the default kernel compression algorithm is moved to lz4 on most architectures. The default initramfs compression algorithm has also changed to lz4 on all architectures. Toolchain Upgrades: It also brings new upstream releases of glibc 2.30, OpenJDK 11, Rust 1.37, GCC 9.2, updated Python 3.7.5, Python 3.8.0 (interpreter only), ruby 2.5.5, php 7.3.8, perl 5.28.1, golang 1.12.10. Read More: Ubuntu has decided to drop i386 (32-bit) architecture from Ubuntu 19.10 onwards Security Improvements Ubuntu 19.10 explores additional default hardening options that are enabled in GGC like support for both stack clash protection and control-flow integrity protection. Ubuntu Desktop GNOME 3.34 desktop: Ubuntu 19.10 includes GNOME 3.34 which includes a lot of bug fixes, some new features and a significant improvement in responsiveness and speed. It allows to group icons in the Activities overview, has improved wallpaper and wi-fi settings. ZFS on root: This feature is included as an experimental feature in this release. Users can create the ZFS file system and also partition the layout from the installer directly. Read More: Ubuntu 19.10 will now support experimental ZFS root file-system install option NVIDIA-specific improvements: The driver is now included in the ISO and has improved startup reliability when the NVIDIA driver is in use.  Ubuntu 19.10 also brings improved smoothness and frame rates for NVIDIA. Other new features in Ubuntu 19.10 A USB drive can be plugged in and accessed directly from the dock. New themes like Yaru light and dark variants are now available. Support for DLNA sharing is now available by default. Ubuntu Server Images: Ubuntu 19.10 prefers the production-ready ppc64el and arm64 live-server ISO images to install Ubuntu Server on bare metal on the two architectures. Raspberry Pi: The Raspberry Pi 32-bit and 64-bit preinstalled images (raspi3) are supported in this release. Also, Ubuntu images will now support almost all the devices of the Raspberry family Pi 2, Pi 3B, Pi 3B+, CM3, CM3+, Pi 4. Users have appreciated the new features in Ubuntu 19.10. https://twitter.com/dont39350/status/1184902506238926850 https://twitter.com/ImpWarfare/status/1184844081576456193 https://twitter.com/robinjuste/status/1183891524242857986 These are some of the selected updates in Ubuntu 19.10, read the release notes for more information. You can also check out the Ubuntu blog for more details on the release. Swift shares diagnostic architecture improvements that will be part of the Swift 5.2 release Microsoft launches Open Application Model (OAM) and Dapr to ease developments in Kubernetes and microservices What to expect from D programming language in the near future Canonical, the company behind the Ubuntu Linux distribution, was hacked; Ubuntu source code unaffected Xubuntu 19.04 releases with latest Xfce package releases, new wallpapers and more
Read more
  • 0
  • 0
  • 20291
Modal Close icon
Modal Close icon