One more Linux Magazine
In many cases, to manage your Linux servers, you can need to allow remote access and this can be done via the Secure Shell (SSH). Since many years ago, Linux systems can use the native terminal to use SSH but it was not the case for Windows systems which need some tools to be installed.
Windows systems have seen many improvements so that you don’t need to install a tool but you can use native tools which are available. In this tutorial, we will learn how to ssh a Linux machine from Windows with the native tools.
Secure Shell is a secure and encrypted connection protocol allowing remote and secure sign-ins over unsecured connections. The connection works in the client-server mode, so the connection is established by the SSH client connecting to the SSH server.
SSH offers several options for user authentication and the most common ones are passwords and public key authentication methods:
Windows machines now allow you to use native tools to establish a SSH connection but you need first to make sure that the feature Openssh windows client is installed. Normally is not installed by default so you will need first to do it. Go to Windows -> Settings -> Apps -> Manage optional feature
Click Add a feature
Select OpenSSH Client and then install.
Now it’s installed
Now you can decide to use the command prompt or Windows PowerShell to access your Linux server via ssh.
The Windows Powershell native tool allows you to remotely connect to a server via ssh. You just have to open it with Windows + r then hit the key A
Now enter the command the ssh command for the connection to your remote Linux server: ssh [email protected]
To remotely access your server via the command, you just have to launch it with the key combination Windows + r and then enter cmd
Now in the command prompt, you can use the ssh command as with powershell
Now you know how you can connect to your remote Linux server with SSH with the native tools offered by Windows. You can choose to use putty tool as well but now it’s easiest and more comfortable to use the tools which are offered by default.
To me, it’s a miracle how every tiny article on OSNews.com, or any other tech-site, ends up in people shouting all sorts of nonsense at each other like “Linux is gonna bring back Elvis”, “Windows shot president Kennedy”, “Linux kept the cold war cold” or “Bill Gates wants to buy the moon and charge people for looking at it”. Do these people really know what they are saying, or are they just going with the Open-Source flow? Update: Rebuttal article here.Editorial Notice: All opinions are those of the author and not necessarily those of osnews.com
General Note: Please forgive any grammar mistakes as the author is not a native english speaker.
Intro
I tend to think the latter. Not because I am not a Linux fan (I happily set up my Computer with Mandrake about two years ago, they are still merrily in love), but because I have not heard anything new in the past two years. It is always “my god, not another security hole in Windows 95/98/98SE/ME/2000/XP/Server 2003”, “Microsoft aggressively bought company X”, “Microsoft launches another way to protect their software” and “Microsoft software is too exspensive”. And Linux, on the other hand, is all bliss.
Well, I think Linux is not all “bliss”. Linux would be all “bliss” if we forget the slow boot-up/shutdown times, if we forget the lousy hardware support for, let’s say, Ati products (Ati being the number two in graphics cards!), if we forget the “geek” image of Linux, if we forget the fact that some distributions suddenly have to be paid for, if we forget that some distributions suddenly get discontinued, if we forget the crappy way software is installed (with the exception of apt-get, or so I’ve heard).
You can go the same way when it comes to Windows. Windows would be all hell if we forget the ease with which it is installed, if we forget the great hardware support, if we forget the uniform look of all the programs, if we forget InstallShield and look-a-likes, if we forget the clear structure (Program Files, My Documents etc, and of course this only goes for the not-so-technical end-user), if we forget Windows Update (still beats the Distribution-specific update tools, in my opinion).
If you confront Linux addicts with the disadvantages I just named, you always get the same reaction: “When Linux becomes (more) mainstream, those problems will disappear.” Well, I think you should turn that around: Linux will become (more) mainstream, when those problems are solved, or at least addressed. Your OS can be great when it comes to its inner workings, but it are the looks of the OS that really matter to the masses. Would Marylin Monroe have become as famous if she was not so darn pretty? I do not think so. I mean, consumers do not want to wait forever for their PC to boot (you can read a Donna Tart in the meantime… twice), they do not want twelve different applications for one task, they do not want to choose between six different Window Managers, even though all of them are quite good. I mean, do you line up six tv’s in your living room just because they look a bit different from each other? Again, I do not think so (imagine the remote-control interference…).
What Should We Do?
So, what should happen to Linux in order to gain more marketshare at the cost of Windows? Well, a lot has been said when it comes to this particular issue.
I think the major Distributions should all “join hands” to create one version of Linux, with one desktop, a uniform look, with one update system and so on. They can still develop their own Distributions (for the fans, I do not think my Computer and Mandrake will ever divorce). By creating a standard, you will make it more accessible for the masses. Just look at the dvd recording standards now: the number of standards are really stopping people from buying a dvd recorder. They are heavily influenced by articles stating the risk of buying one: “Your standard may be unsupported in a few years”.
It will be no problem if Linux XP (couldn’t resist the temptation 😉 , sorry) will cost something, they can spend the earned money on research. The newly developed applications can first be put in the Distributions, and, when the community is satisfied, they can be integrated into the next Linux version, Linux Longhorn (okay, this is getting silly). This way you get the best of both worlds: the knowledge, experience and diversity of the Open-Source world, combined with the easiness and clarity of standardized software. A very good example is, in my eyes, LindowsOS 4.0. I have used it for a couple of weeks now and I must say I am impressed. Despite critizism from the Open-Source commmunity (“It’s too Windows”, “It’s not free” and “They don’t supply source-code (which is a plain lie, by the way)”), I believe LindowsOS is kind of what that new standardized Linux should look like.
Of course that kind of takes away the essence of the Open-Source concept. Open-Source is all about letting everybody not only use the software, bu also letting everybody improve the software. This has led to a diversity in the available software. This is a good thing, if you are an expert willing to put time and effort into your OS, but if you are not, than Linux just isn’t for you, at this moment.
But, as always, this is just my opinion. So please, do not send any suicide penguins my way…
Transfer.sh is a simple, easy and fast service for file sharing from the command-line. It allows you to upload up to 10GB of data and files are stored for 14 days, for free.
You can maximize amount of downloads and it also supports encryption for security. It supports the local file system (local); together with s3 (Amazon S3), and gdrive (Google Drive) cloud storage services.
Transfer.sh – Easy File Sharing in Linux Terminal
It is designed to be used with the Linux shell. In addition, you can preview your files in the browser. In this article, we will show how to use transfer.sh in Linux.
To upload a file, you can use the curl program with the --upload-file option as shown.
$ curl --upload-file ./tecmint.txt https://transfer.sh/tecmint.txt
To download your file, a friend or colleague can run the following command.
$ curl https://transfer.sh/Vq3Kg/tecmint.txt -o tecmint.txt
You can upload multiple files at once, for example:
$ curl -i -F filedata=@/path/to/tecmint.txt -F filedata=@/path/to/usernames.txt https://transfer.sh/
To encrypt your files before the transfer, use the following command (you must have the gpg tool installed on the system). You will be prompted to enter a password to encrypt the file.
$ cat usernames.txt | gpg -ac -o- | curl -X PUT --upload-file "-" https://transfer.sh/usernames.txt
To download and decrypt the above file, use the following command:
$ curl https://transfer.sh/11Rnw5/usernames.txt | gpg -o- > ./usernames.txt
Transfer.sh also supports the wget tool. To upload a file, run.
$ wget --method PUT –body-file=./tecmint.txt https://transfer.sh/tecmint.txt -O --nv
To use the short transfer command, add an alias to your .bashrc or .zshrc startup file.
$ vim ~/.bashrc OR $ vim ~/.zshrc
Then add the lines below in it (you can only choose one tool, either curl or wget).
##using curl
transfer() {
curl --progress-bar --upload-file "$1" https://transfer.sh/$(basename $1) | tee /dev/null;
}
alias transfer=transfer
##using wget
transfer() {
wget -t 1 -qO - --method=PUT --body-file="$1" --header="Content-Type: $(file -b --mime-type $1)" https://transfer.sh/$(basename $1);
}
alias transfer=transfer
Save the changes and close the file. Then source it to apply the changes.
$ source ~/.bashrc OR $ source ~/.zshrc
From now on, you upload a file using the transfer command as shown.
$ transfer users.list.gz
To setup your own sharing server instance, download the program code from the Github repository.
You can find more information and sample use cases in the project homepage: https://transfer.sh/
Transfer.sh is a simple, easy and fast service for file sharing from the command-line.
Today we feature a very interesting interview with Havoc Pennington. Havoc works for Red Hat, he is heading the desktop team, while he is well known also for his major contributions to GNOME, his GTK+ programming book, plus the freedesktop.org initiative which aims to standardize the X11 desktop environments. In the following interview we discuss about the changes inside Red Hat, Xouvert, freedesktop.org and Gnome’s future, and how Linux, in general, is doing in the desktop market.
1. Looking Red Hat’s recent press releases and web site lately, it reveals a new, stronger effort to shift focus further into the Enterprise and leaving Red Hat Linux to the hands of the community for the home/desktop market. This seems to leave a “hole” in the previous target of Red Hat at the “Corporate Desktop market”. The new Red Hat Linux might sound like “power to the people”, but to me sounds like an action that will have consequences (good & bad) in the quality, testing, development of what we got to know as your “corporate/desktop” product. Given the fact that Red Hat is the No1 Linux distribution on the planet, do you think that this new direction will slow down the Linux penetration to the desktop market?
Havoc Pennington: In my view it’s a mistake to create an “Enterprise vs. Desktop” contrast; these are largely separate dimensions. There are enterprise desktops, enterprise servers, consumer desktops, and consumer servers. Quite possibly small business desktops and servers are another category in between.
I don’t think we’ll see a slowdown in Linux penetration into the desktop market. In fact I hope to see it speed up. Today there are many large software companies making investments in the Linux desktop.
2. How have things changed internally after the [further] focus shift to Enterprise? Is your desktop team still fully working on Gnome/GTK+/X/etc or have developers been pulled into other projects that are more in line with this new focus at Red Hat?
Havoc Pennington: We’re still working on the desktop, more so than ever. (Including applications such as Mozilla, OpenOffice, and Evolution, not just the base environment.)
3. In the past (pre-SCO), Red Hat has admitted that was growing wary of patent issues that might arise in the future. Do you believe that desktop open source software written by many different individuals around the globe might be infringing on patents in some cases without the knowledge of these developers? At the end of the day, we have seen some patents that were issued so shortsightedly that many have said that writing software is almost impossible nowadays. What kind of solution for this issue might OSS software developers find, to ensure a future that is not striken by lawsuits left and right?
Havoc Pennington: As you know we’ve been more aggressive than other Linux vendors about removing potentially patented software from our distribution, specifically we took a lot of criticism for removing mp3 support.
One strategy for helping defend the open source community is to create defensive patents, as described here.
Another strategy is the one taken by Lawrence Rosen in the Academic Free License and Open Software License.
These licenses contain a “Termination for Patent Action” clause that’s an interesting approach.
Political lobbying and education can’t hurt either. These efforts become stronger as more people rely upon open source software.
4. What major new features are scheduled for GTK+ 2.4/2.6 and for the future in general? Once, you started a C++ wrapper for GTK+, but then the project got sterile. Do you believe that Gnome needs a C++ option, and if yes, do you believe that Gtkmm is a good one? Are there plans to sync GTK+ and Gtkmm more often and include it by default on Gnome releases?
Havoc Pennington: GTK+ 2.4 and 2.6 plans are pretty well described here.
One theme of these releases are to make GTK+ cover all the GUI functionality provided historically by libgnomeui. So there will be a single clear GUI API, rather than “plain GTK+” and “GNOME libs” – at that point being a “GNOME application” is really just a matter of whether you follow the GNOME user interface guidelines, rather than an issue of which libs you link to. This cuts down on bloat and developer confusion.
The main user-visible change in 2.4 is of course the new file selector.
The other user-visible effects of 2.4 and 2.6 will mostly be small tweaks and improved consistency between applications as they use the new standard widgets.
At some point we’ll support Cairo which should allow for some nice themes. Cairo also covers printing.
Regarding C++, honestly I’m not qualified to comment on the current state of gtkmm, because I haven’t evaluated it in some time. I do think a C++ option is important. There are two huge wins I’d consider even more important for your average one-off in-house simple GUI app though. 1) to use a language such as Python, Java, C#, Visual Basic, or whatever with automatic memory management, high-level library functions, and so forth; 2) use a user interface builder such as Glade. Both of those will save you more time than the difference between a C and a C++ UI toolkit.
5. What do you think of the XFree86 fork, Xouvert? Do you support the fork, and if yes, what exactly you want to see changed with Xouvert (feature-wise and architecture-wise for X)?
Havoc Pennington: The huge architectural effort I want to see in the X server is to move to saving all the window contents and using the 3D engine of the graphics cards, allowing transparency, faster redraws, nice visual effects, and thumbnailing/magnification, for example.
The trick is that there are *very* few people in the world with the qualifications to architect this change. I don’t know if the Xouvert guys have the necessary knowledge, but if they do that would be interesting. It may well be that no single person understands how to do this right; we may need a collaboration between toolkit people, X protocol people, and 3D hardware experts.
Aside from that, most of the changes to X I’d like to see aren’t really to the window system. Instead, I’d like us to think of the problem as building a base desktop platform. This platform would include a lot of things currently in the X tarball, a lot of things currently on freedesktop.org, and a lot of things that GNOME and KDE and GTK+ and Qt are doing independently. You can think of it as implementing the common backend or framework that GUI toolkits and applications are ported to when they’re ported to Linux.
This may be of interest. If we can negotiate the scary political waters, I’d like to see the various X projects, freedesktop.org, and the desktop environments and applications work together on a single base desktop platform project. With the new freedesktop.org server I’m trying to encourage such a thing.
6. How are things with freedesktop.org; what is its status? Do these standards get implemented in KDE and Gnome, or do they find resistance by hardcore devs on either projects? When do you think KDE and Gnome will reach a good level of interoperability as defined by freedesktop.org? What work has being done so far?
Havoc Pennington: freedesktop.org is going pretty well, I recently posted about the status of the hosting move. See here, I also had a lot of fun at the KDE conference in Nove Hrady and really enjoyed meeting a lot of quality developers I hadn’t met before.
I find that hardcore devs understand the importance of what we’re trying to do, though they also understand the difficulty of changing huge codebases such as Mozilla, OpenOffice, GNOME, or KDE so are understandably careful.
There are people who think of things in “GNOME vs. KDE” terms but in general the people who’ve invested the most time are interested in the bigger picture of open source vs. proprietary, Linux vs. Microsoft, and democratizing access to software.
Of course everyone has their favorite technologies – I think GNOME is great and have a lot of investment in it, and I also like Emacs and Amazon.com and Red Hat Linux. These preferences change over time. When it comes down to it the reason I’m here is larger than any particular technology.
As to when freedesktop.org will achieve interoperability, keep in mind that currently any app will run with any desktop. The issue is more sustaining that fact as the desktop platforms add new bells and whistles; and factoring new features down into the base desktop platform so that apps are properly integrated into any desktop. So it’s a process that I don’t think will ever end. There are always new features and those will tend to be tried out in several apps or desktops before they get spec’d out and documented on the freedesktop.org level.
7. Gnome 2.4 was released last week. Are you satisfied with the development progress of Gnome? What major features/changes do you want to see in Gnome in the next couple of years?
Havoc Pennington: I’m extremely satisfied with GNOME’s progress. Time based releases (see here
for the long definition) are the smartest thing a free software project can do.
This mail has some of my thoughts on what we need to add.
Honestly though the major missing bits of the Linux desktop are not on the GNOME/KDE level anymore. The desktop environments can be endlessly tweaked but they are pretty usable already.
We need to be looking at issues that span and integrate the large desktop projects – WINE, Mozilla, OpenOffice, Evolution on top of the desktops, X below them. And integrate all of them with the operating system.
Some of the other major problems, as explained here, have “slipped through the cracks” in that they don’t clearly fall under the charter of any of the existing large projects.
And of course manageability, administration, security, and application features.
8. Your fellow Red Hat engineer Mike Harris said recently that “There will be a time and a place for Linux on the home desktop. When and where it will be, and wether it will be something that can turn a profit remains to be seen. When Red Hat believes it may be a viable market to enter, then I’m sure we will. Personally, in my own opinion, I don’t think it will be viable for at least 1.5 – 2 years minimum.” Do you agree with this time frame and if yes, what parts exactly need to be “fixed/changed” in the whole Linux universe (technical or not) before Linux becomes viable to the home/desktop market?
Havoc Pennington: I wouldn’t try to guess the timeframe exactly. My guess would be something like “0 to 7 years” 😉
On the technology side, we need some improvements to robustness, to hardware handling, to usability.
However the consumer barriers have a lot to do with consumer ISV and IHV support. And you aren’t going to get that until you can point to some desktop marketshare. That’s why you can’t bootstrap the Linux desktop by targeting consumers. You need to get some initial marketshare elsewhere.
There’s also the business issue that targeting consumers involves very expensive mass market advertising.
9. Have you had a look at the Mac OS X 10.3 Panther previews? Apple is introducing some new widgets, like the new Tabs that look like buttons instead of tabs, and there is of course, Expose, which by utilizing the GL-based QuartzExtreme, offers new usability enhancements, plus cool and modern eye-candy. Do you think that X with GTK+/Gnome will be able to have such innovations in a timely manner, or will it take some years before we see those to a common Linux desktop?
Havoc Pennington: I haven’t tried Panther, though I saw some screenshots and articles.
As I mentioned earlier, the big X server feature I think we need is to move to this kind of 3D-based architecture. If we got the right 2 or 3 people working on it today, we could have demoware in a few months and something usable in a couple of years. I’m just making up those numbers of course.
However, nobody can predict when the right 2 or 3 people will start to work on it. As always in free software, the answer to “when will this be done?” is “faster if you help.”
One stepping stone is to create a robust base desktop platform project where these people could do their work, and some of us are working hard on that task.
10. How do you see the Linux and Unix landscape today? Do you feel that Linux is replacing Unix slowly but steadily, or do they follow parallel and different directions in your opinion?
Havoc Pennington: I would say that the nails are firmly in the UNIX coffin, and it’s just a matter of time.
Improve your Python testing even more.
In my last two articles, I introduced pytest, a library for testing Python code (see “Testing Your Code with Python’s pytest” Part I and Part II). pytest has become quite popular, in no small part because it’s so easy to write tests and integrate those tests into your software development process. I’ve become a big fan, mostly because after years of saying I should get better about testing my software, pytest finally has made it possible.
So in this article, I review two features of pytest that I haven’t had a chance to cover yet: fixtures and code coverage, which will (I hope) convince you that pytest is worth exploring and incorporating into your work.
When you’re writing tests, you’re rarely going to write just one or two. Rather, you’re going to write an entire “test suite”, with each test aiming to check a different path through your code. In many cases, this means you’ll have a few tests with similar characteristics, something that pytest handles with “parametrized tests”.
But in other cases, things are a bit more complex. You’ll want to have some objects available to all of your tests. Those objects might contain data you want to share across tests, or they might involve the network or filesystem. These are often known as “fixtures” in the testing world, and they take a variety of different forms.
In pytest, you define fixtures using a combination of the pytest.fixture decorator, along with a function definition. For example, say you have a file that returns a list of lines from a file, in which each line is reversed:
def reverse_lines(f):
return [one_line.rstrip()[::-1] + '\n'
for one_line in f]
Note that in order to avoid the newline character from being placed at the start of the line, you remove it from the string before reversing and then add a '\n' in each returned string. Also note that although it probably would be a good idea to use a generator expression rather than a list comprehension, I’m trying to keep things relatively simple here.
If you’re going to test this function, you’ll need to pass it a file-like object. In my last article, I showed how you could use a StringIO object for such a thing, and that remains the case. But rather than defining global variables in your test file, you can create a fixture that’ll provide your test with the appropriate object at the right time.
Here’s how that looks in pytest:
@pytest.fixture
def simple_file():
return StringIO('\n'.join(['abc', 'def', 'ghi', 'jkl']))
On the face of it, this looks like a simple function—one that returns the value you’ll want to use later. And in many ways, it’s similar to what you’d get if you were to define a global variable by the name of “simple_file”.
At the same time, fixtures are used differently from global variables. For example, let’s say you want to include this fixture in one of your tests. You then can mention it in the test’s parameter list. Then, inside the test, you can access the fixture by name. For example:
def test_reverse_lines(simple_file):
assert reverse_lines(simple_file) == ['cba\n', 'fed\n',
↪'ihg\n', 'lkj\n']
But it gets even better. Your fixture might act like data, in that you don’t invoke it with parentheses. But it’s actually a function under the hood, which means it executes every time you invoke a test using that fixture. This means that the fixture, in contrast with regular-old data, can make calculations and decisions.
You also can decide how often a fixture is run. For example, as it’s written now, this fixture will run once per test that mentions it. That’s great in this case, when you want to compare with a list or file-like structure. But what if you want to set up an object and then use it multiple times without creating it again? You can do that by setting the fixture’s “scope”. For example, if you set the scope of the fixture to be “module”, it’ll be available throughout your tests but will execute only a single time. You can do this by passing the scope parameter to the @pytest.fixture decorator:
@pytest.fixture(scope='module')
def simple_file():
return StringIO('\n'.join(['abc', 'def', 'ghi', 'jkl']))
I should note that giving this particular fixture “module” scope is a bad idea, since the second test will end up having a StringIO whose location pointer (checked with file.tell) is already at the end.
These fixtures work quite differently from the traditional setup/teardown system that many other test systems use. However, the pytest people definitely have convinced me that this is a better way.
But wait—perhaps you can see where the “setup” functionality exists in these fixtures. And, where’s the “teardown” functionality? The answer is both simple and elegant. If your fixture uses “yield” instead of “return”, pytest understands that the post-yield code is for tearing down objects and connections. And yes, if your fixture has “module” scope, pytest will wait until all of the functions in the scope have finished executing before tearing it down.
This is all great, but if you’ve ever done any testing, you know there’s always the question of how thoroughly you have tested your code. After all, let’s say you’ve written five functions, and that you’ve written tests for all of them. Can you be sure you’ve actually tested all of the possible paths through those functions?
For example, let’s assume you have a very strange function, only_odd_mul, which multiplies only odd numbers:
def only_odd_mul(x, y):
if x%2 and y%2:
return x * y
else:
raise NoEvenNumbersHereException(f'{x} and/or {y}
↪not odd')
Here’s a test you can run on it:
def test_odd_numbers():
assert only_odd_mul(3, 5) == 15
Sure enough, the test passed. It works great! The software is terrific!
Oh, but wait—as you’ve probably noticed, that wasn’t a very good job of testing it. There are ways in which the function could give a totally different result (for example, raise an exception) that the test didn’t check.
Perhaps it’s easy to see it in this example, but when software gets larger and more complex, it’s not going to be so easy to eyeball it. That where you want to have “code coverage”, checking that your tests have run all of the code.
Now, 100% code coverage doesn’t mean that your code is perfect or that it lacks bugs. But it does give you a greater degree of confidence in the code and the fact that it has been run at least once.
So, how can you include code coverage with pytest? It turns out that there’s a package called pytest-cov on PyPI that you can download and install. Once that’s done, you can invoke pytest with the --cov option. If you don’t say anything more than that, you’ll get a coverage report for every part of the Python library that your program used, so I strongly suggest you provide an argument to --cov, specifying which program(s) you want to test. And, you should indicate the directory into which the report should be written. So in this case, you would say:
pytest --cov=mymul .
Once you’ve done this, you’ll need to turn the coverage report into something human-readable. I suggest using HTML, although other output formats are available:
coverage html
This creates a directory called htmlcov. Open the index.html file in this directory using your browser, and you’ll get a web-based report showing (in red) where your program still lacks coverage. Sure enough, in this case, it showed that the even-number path wasn’t covered. Let’s add a test to do this:
def test_even_numbers():
with pytest.raises(NoEvenNumbersHereException):
only_odd_mul(2,4)
And as expected, coverage has now gone up to 100%! That’s definitely something to appreciate and celebrate, but it doesn’t mean you’ve reached optimal testing. You can and should cover different mixtures of arguments and what will happen when you pass them.
If you haven’t guessed from my three-part focus on pytest, I’ve been bowled over by the way this testing system has been designed. After years of hanging my head in shame when talking about testing, I’ve started to incorporate it into my code, including in my online “Weekly Python Exercise” course. If I can get into testing, so can you. And although I haven’t covered everything pytest offers, you now should have a good sense of what it is and how to start using it.
There are a lot of different ways to track email, and different techniques can lie anywhere on the spectrum from marginally acceptable to atrocious. Responsible tracking should aggregate a minimal amount of anonymous data, similar to page hits: enough to let the sender get a sense of how well their campaign is doing without invading users’ privacy. Email tracking should always be disclosed up-front, and users should have a clear and easy way to opt out if they choose to. Lastly, organizations that track should minimize and delete user data as soon as possible according to an easy-to-understand data retention and privacy policy.
Unfortunately, that’s often not how it happens. Many senders, including the U.S. government, do email tracking clumsily. Bad email tracking is ubiquitous, secretive, pervasive, and leaky. It can expose sensitive information to third parties and sometimes even others on your network. According to a comprehensive study from 2017, 70% of mailing list emails contain tracking resources. To make matters worse, around 30% of mailing list emails also leak your email address to third party trackers when you open them. And although it wasn’t mentioned in the paper, a quick survey we did of the same email dataset they used reveals that around 80% of these links were over insecure, unencrypted HTTP.
Here are some friendly suggestions to help make tracking less pervasive, less creepy, and less leaky.
Read more at EFF
There is a new tool available: MultiBootUSB.
What is MultiBootUSB?
MultiBootUSB is a software/utility to create multi boot live Linux on a removable USB disk. It is similar to UNetbootin but many distros can be installed, provided you have enough space on the disk. MultiBootUSB also provides an option to uninstall distro(s) at any time, if you wish.
MultiBootUSB allows you to do the following:
– Install multiple live Linux and other Operating Systems to a USB disk and make it bootable without erasing existing data.
– Ability to uninstall installed OS later.
– Write ISO image directly to a USB disk (you can think of GUI for Linux dd command).
– Boot ISO images directly without rebooting your system using QEMU option.
– Boot bootable USBs without rebooting your system using QEMU option.
– Boot USB on UEFI/EFI system through GRUB2 bootloader (limited support).
Installation:
sudo apt update
sudo apt install python3-multibootusb
The MultiBootUSB GitHub project page: github.com/mbusb/multibootusb
The project author is Sundar; and co-author is Ian Bruce.
At organizations everywhere, managing the use of open source software well requires the participation of business executives, the legal team, software architecture, software development and maintenance staff and product managers. One of the most significant challenges is integrating all of these functions with their very different points of view into a coherent and efficient set of practices.
More than ever, it makes sense to investigate the many free and inexpensive resources for open source management that are available, and observe the practices of professional open source offices that have been launched within companies ranging from Microsoft to Oath to Red Hat.
The Linux Foundation’s Fundamentals of Professional Open Source Management (LFC210) course is a good place to start. The course is explicitly designed to help individuals in disparate organizational roles understand the best practices for success.
The course is organized around the key phases of developing a professional open source management program:
The Linux Foundation also offers a free ebook on open source management: Enterprise Open Source: A Practical Introduction. The 45-page ebook can teach you how to accelerate your company’s open source efforts, based on the experience of hundreds of companies spanning more than two decades of professional enterprise open source management. The ebook covers:
Official open source programs play an increasingly significant role in how DevOps and open source best practices are adopted by organizations, according to a survey conducted by The New Stack and The Linux Foundation (via the TODO Group). More than half of respondents to the survey (53 percent) across many industries said their organization has an open source software program or has plans to establish one.
“More than anything, open source programs are responsible for fostering open source culture,” the survey’s authors have reported. “By creating an open source culture, companies with open source programs see the benefits we’ve previously reported, including increased speed and agility in the development cycle, better license compliance and more awareness of which open source projects a company’s products depend on.”
How can your organization professionally create and manage a successful open source program, with proper policies and a strong organizational structure? The Linux Foundation offers a complete guide to the process, available here for free. The guide covers an array of topics for open source offices including: roles and responsibilities, corporate structures, elements of an open source management program, how to choose and hire an open source program manager, and more.
The free guide also features contributions from open source leaders. “The open source program office is an essential part of any modern company with a reasonably ambitious plan to influence various sectors of software ecosystems,” notes John Mark Walker, Founder of the Open Source Entrepreneur Network (OSEN) in the guide. “If a company wants to increase its influence, clarify its open source messaging, maximize the clout of its projects, or increase the efficiency of its product development, a multifaceted approach to open source programs is essential.”
Interested in even more on professional open source management? Don’t miss The Linux Foundation’s other free guides, which delve into tools for open source management, how to measure the success of an open source program, and much more.
This article originally appeared at The Linux Foundation
My First Cluster – Getting started with MongoDB Atlas!
We will be exploring one innovation in data storage system known as MongoDB.
MongoDB provides schema-less design, high performance, high availability, and automatic scaling qualities which have now become a need and cannot be satisfactorily met by traditional RDBMS systems.
Speaker: Jay Gordon, Cloud Developer Advocate, MongoDB
Agenda:
• Intro to MongoDB / document model / compatibility
• Guided lesson on how to setup
• Connecting and creating a document
• how to use as part of an app
Required for class:
• Virtual Machine (if you need a vm email organizers to get set-up)
• Command line experience
• Basic understand of distributed systems and cloud computing (API’s, virtual machines, basic understanding of HTTP, PUT/GET, knowledge of AWS/Azure/Goggle Compute)
• Community Server: https://mongodb.com/download
• Atlas: https://cloud.mongodb.com/