After Microsoft fell in love with Linux (what has popularly come to be known as “Microsoft Loves Linux”), PowerShell which was originally a Windows-only component, was open-sourced and made cross-platform on 18 August 2016, available on Linux and Mac OS.
PowerShell is a task automation and configuration management system developed by Microsoft. It is made up of a command language interpreter (shell) and scripting language built on the .NET Framework. It offers complete access to COM (Component Object Model) and WMI (Windows Management Instrumentation), thereby allowing system administrators to carry out administrative tasks on both local and remote Windows systems
Read more at Tecmint
If you’re interested in running a complex Kubernetes system across several different cloud environments, you should check out what Bob Wise and his team at Samsung SDS call “Control Plane Engineering.”
Wise, during his keynote at CloudNativeCon last year, explained the concept of building a system that sits on top of the server nodes to ensure better uptime and performance across multiple clouds, creates a deployment that’s easily scaled by the ClusterOps team, and covers long-running cluster requirements.
“[If you believe] the notion of Kubernetes as a great way to run the same systems on multiple clouds, multiple public clouds, and multiple kinds of private clouds is really important, and if you care about that, you care about control plane engineering,” Wise said.
By focusing on that layer, and sharing configuration and performance information with the Kubernetes community, Wise said larger Kubernetes deployments can become easier and more manageable.
”One of the things we’re trying to foster, trying to build some tooling and make some contribution around is a way for members of the community to grab their cluster configuration, what they have including things like setting of cluster, be able to grab that, dump that, and capture that and export it for sharing, and also to take performance information from that cluster and do the same,” Wise said. “The goal here is, across a wide range of circumstances, to be able to start compare notes across the community.”
For the work Wise and his team have done, the Control Plane involves four separate parts that sit atop the nodes to make sure things work optimally despite occasional machine failure and broken nodes.
The Control Plane includes:
An API Server on the front end through which all the components interact,
A Scheduler to assign pods to nodes,
The ETCD, a distributed database system where cluster state is maintained, and
A Controller Manager, which is the home for embedded control loops like replica sets, deployments, jobs, etc.
The best way to run the system so that it has some level of allocation automation is through Kubernetes self-hosting, Wise said. But that requires some “tricky bootstrapping” to build it. In the end, it’s worth it if you’re running a large cluster, however.
“The idea here is it’s a system entirely running as Kubernetes objects,” he said. “You have this common operation set. It’s going to make scaling … and HA easier.”
One piece that is perhaps better not to try to build on your own is a load balancer for the API Server, which can get bogged down because it’s a bottleneck into the system. Wise said using a cloud provider’s load balancer is the easiest, and in the end, probably best solution.
“This load balancer, this is a very key part to the overall system performance and availability,” Wise said. “The public cloud providers have put enormous investment into really great solutions here. Use them and to be happy.
“It’s worth the configuration drift that happens between multiple deployments,” Wise continued. “I’d also say again, if you have on premises and you’re trying to do deployments and you already have these load balancers then they work well, they’re pretty simple to configure usually. The configurations that Kubernetes requires for support are not especially complicated. If you have them, use them, be happy but I wouldn’t recommend going and buying those appliances new.”
Watch the complete presentation below:
Want to learn more about Kubernetes? Get unlimited access to the new Kubernetes Fundamentals training course for one year for $199. Sign up now!
Scripting languages (aka Very High-Level Languages or VHLLs), such as Python, PHP, and JavaScript are commonly used in desktop, server, and web development. And, their powerful built-in functionality lets you develop small useful applications with little time and effort, says Paul Sokolovsky, IoT engineer at Linaro. However, using VHLLs for deeply embedded development is a relatively recent twist in IoT.
Linux.com: Can you please give our readers some background on VHLLs?
Paul Sokolovsky: Very High Level Languages have been a part of the computer science and information technologies landscape for several decades now. Perhaps the first popular scripting language was a Unix shell (sh), although it’s rarely considered a VHLL, but rather a domain-specific language, due to its modest feature set. However, the first truly record-breaker VHLLs were Perl (1987) and Tcl (1988), soon followed by Python (1991), Ruby (1995), PHP (1995), JavaScript (1995), and many others.
The distinctive features of VHLLs are their interpreted nature (from the user’s point of view, there may be sophisticated compilers inside), built-in availability of powerful data types like arbitrary-sized lists and mappings, sizable standard library, and external modules system allowing users to access even larger third-party libraries. All that is coupled with a general easy feel (less typing, no build times, etc.) and an easy learning curve.
Linux.com: What are the benefits of these languages for development?
Sokolovsky: The benefits stem from the features described above. One can start with a scripting language quite easily and learn it quickly. Many VHLLs offer a powerful interactive mode, so you don’t need to read thick manuals to get started but can explore and experiment right away. Powerful built-in functionality allows you to develop small useful applications — scripts — with little time and effort (that’s where the “scripting languages” name came from). Moving to larger applications, vast third-party libraries and an easy-to-use module system make developing them also streamlined and productive.
Linux.com: How does scripting for embedded platforms differ from development for other platforms?
Sokolovsky: With all the exciting capabilities of VHLLs discussed above, there’s an idea — why we can’t enjoy all (or at least some) benefits of them when developing for embedded devices? And by “embedded devices” I mean here not just small Linux systems with 8-32MB of RAM, but deeply embedded systems running on microcontrollers (MCUs) with mere kilobytes of memory. Small, and sometimes really scarce, resources definitely add complexity to this idea. Another issue is device access and interaction. Embedded devices usually don’t have displays and keyboards, but fortunately the answer is known for decades thanks to Unix — just use a terminal connection over a serial (UART). Of course, on a host side, it can be hidden behind a graphical IDE, which some users prefer.
So, with all the differences the embedded devices have, the idea is to provide as familiar a working environment as possible. That’s on one side of the spectrum and, on the other, the idea is to make it as scaled down as possible to accommodate even the smallest of devices. These conflicting aims require embedded VHLLs implementations to be highly configurable, to adjust for the needs of different projects and hardware.
Linux.com: What are the specific challenges of using these languages for IoT? How do you address memory constraints, for example?
Sokolovsky: It’s definitely true that the interpreter consumes scarce hardware resources. But nowadays the most precious resource is the human time. Whether you are an R&D engineer, a maker with only a few hours on weekend, a support engineer overwhelmed with bugs and security issues, or a project manager planning a product — you likely don’t have extra time on your hands. The idea is to deliver the productivity of VHLLs into the hands of embedded engineers.
Nowadays, the state of art is very enabling of this. It’s fair to say that, even of microcontroller units (MCUs), an average now is 16-32KB RAM and 128-256K ROM. That’s just enough to host a core interpreter, a no-nonsense subset of standard library types, some hardware drivers, and a small — but still useful — user application. If you go slightly above the middle line, capabilities raise rapidly — it’s actually a well-known trick from 1970s that using custom bytecode/pcode lets you achieve greater code/feature density than the raw machine code.
There are a lot of challenges on that road, scarcity of RAM being the main one. I write these words on a laptop with 16GB of RAM (and there’re still slowdowns due to swapping), and the 16KB mentioned above is a million times less! And yet, by using carefully chosen algorithms and coding techniques, it’s possible to implement a scripting language that can execute simple applications in that amount of RAM, and fairly complex ones in 128-256K.
There are many technical challenges to address (and which are being successfully addressed), and there wouldn’t be a space to cover them here. Instead, my presentation at OpenIoT Summit will cover experiences and achievements of two embedded scripting languages: MicroPython (Python3 language subset) and Zephyr.js (JavaScript/Node.js subset), both running on top of The Linux Foundation’s Zephyr RTOS, which is expected to do for the IoT industry what Linux did for the mobile and server industries. (The slides will be available afterwards for people who can’t attend OpenIoT Summit.)
Linux.com: Can you give us some examples of applications for which VHLLs are most appropriate? And for which they are inappropriate?
Sokolovsky: Above are many bright prospects for VHLLs, fairly speaking; in embedded, there’s a lot of wishful thinking in that (or hopefully, self-fulfilling prophecy). Where VHLLs in embedded can deliver right now are: rapid prototyping, and educational/maker markets where easy learnability and usage is a must. There are pioneers that use VHLLs in other areas, but generally, it requires more investment into infrastructure and tools. It’s important that such investment be guided by open source principles and be shared, or otherwise it undermines the idea that VHLLs can save their users time and effort.
With that in mind, embedded VHLLs are full-fledged (“Turing complete”) languages suitable for any type of application, subject to hardware constraints. For example, if an MCU is below the thresholds stated above, of a legacy 8-bit micro, good old C is the only choice you can enjoy. Another limit is when you really want to get the most out of the hardware — C or Assembler is the right choice. But, here’s a surprise — the developers of embedded VHLLs thought about that, too, and, for example, MicroPython allows you to combine Python and Assembler in one application.
Where embedded VHLLs excel is configurability and (re)programmability, coupled with flexible connectivity support. That’s exactly what IoT and smart devices are all about, and many IoT applications don’t have to be complex to be useful. Consider, for example, a smart button you can stick anywhere to do any task. But, what if you need to adjust the double-click time? With a scripting language, you can. Maybe you didn’t think about triple-clicks at all, but now find that even four clicks would be useful in some cases. With a scripting language you can change that — easily.
Embedded Linux Conference + OpenIoT Summit North America will be held on February 21 – 23, 2017 in Portland, Oregon. Check out over 130 sessions on the Linux kernel, embedded development & systems, and the latest on the open Internet of Things.
Linux.com readers can register now with the discount code, LINUXRD5, for 5% off the attendee registration price. Register now>>
The following is adapted from The Linux Foundation’s e-book, Open Source Compliance in the Enterprise, by Ibrahim Haddad, PhD.
Education and communication are two essential building blocks in any open source software compliance program. Both help ensure that employees, as well as others outside the organization, possess a good understanding of the organization’s policies governing the use of open source software.
Employee training serves as a venue to publicize and promote the compliance policy and processes within the organization and to foster a culture of compliance.
While clear and consistent messaging — whether it is internally to your employees or externally toward the developer communities of the open source projects you use in your product/software stack — help explain the company’s goals and concerns around open source.
The goal of providing open source and compliance training — formally or informally — is to raise awareness of open source policies and strategies and to build a common understanding around the issues and facts of open source licensing. It also addresses the business and legal risks of incorporating open source software in products and/or software portfolios.
Such training can follow a formal or informal format, depending on the organization’s needs.
Depending on the size of the company and the extent to which open source is included in its commercial offerings, the company can mandate that employees working with open source take formal instructor-led courses, possibly culminating in actual exams.
Informal training channels may include any or all of the following:
• Brown bag seminars: Brown bag seminars are usually presentations made during lunchtime by a company employee or an invited speaker. The goal of these seminars is to present and evoke discussions of the various aspects of incorporating open source in a commercial product or an enterprise software portfolio. These sessions can also include discussions of the company’s compliance program, policies, and processes.
• New employee orientation: In some instances, the Compliance Officer presents on the company’s compliance efforts, rules, policies, and processes to new employees as part of employee orientation, supplying new employees with necessary open source management information: who to talk to, what internal website to visit, how to sign-up for open source and compliance training, etc.
A website or online portal focused on a company’s open source management program helps tie together employee training with internal and external messaging and make it easily accessible.
Companies use portals in two directions: inwards, inside the company; and outwards, as a window to the world and the open source community. The internal portal hosts the compliance policies, guidelines, documents, training, announcements, and access to mailing lists. The external portal offers a public platform for the world and the open source community, as well as a venue to post source code of open source packages, acknowledgements, and other disclosures, in fulfillment of license obligations.
We’ve now covered all seven essential elements of an open source management program, from strategy and process, to staffing and tools, and more. In the next few posts we’ll discuss some common challenges to establishing an open source management program and provide some recommendations on how to overcome these challenges.
Get the open source compliance training you need. Take the free “Compliance Basics for Developers” course from The Linux Foundation. Sign up now!
Read the previous articles in this series:
The 7 Elements of an Open Source Management Program: Strategy and Process
The 7 Elements of an Open Source Management Program: Teams and Tools
Basic Rules to Streamline Open Source Compliance For Software Development
