- wlug - list.wlug.org.nz

Sourceforge going mubar?!
by Ian Young 17 Nov '15

17 Nov '15

Anyone happen to know whether Sourceforge is more than usually impaired at the moment (messed up beyond all recognition)? Any download I attempt is extremely slow, this from two networks. And Australia seems to been excised from the map of mirrors. Don't even get me started on the wall to wall advertising, and the cumbersome process of displaying info on whatever project one is trying to d/l after a d/l has commenced.

2 1

Linux 4.4 Kernel To Bring Raspberry Pi Graphics Driver, Open-Channel SSD Support
by Peter Reutemann 16 Nov '15

16 Nov '15

"Linux 4.4-rc1 has been released. New features of Linux 4.4 include a Raspberry Pi kernel mode-setting driver, support for 3D acceleration by QEMU guest virtual machines, AMD Stoney APU support, Qualcomm Snapdragon 820 support, expanded eBPF virtual machine programs, new hardware peripheral support, file-system fixes, faster SHA crypto support on Intel hardware, and LightNVM / Open-Channel SSD support." -- source: http://linux.slashdot.org/story/15/11/16/0313205 Cheers, Peter -- Peter Reutemann Dept. of Computer Science University of Waikato, NZ +64 (7) 858-5174 http://www.cms.waikato.ac.nz/~fracpete/ http://www.data-mining.co.nz/

2 1

SUSE LEAP 421 live versions
by Ian Young 16 Nov '15

16 Nov '15

This looks interesting and not a large download. http://geckolinux.github.io/ And the inimitable man from Sweden has been at it again in a break from brewing up his Android and Pi versions. http://opsus.exton.net/

1 0

Non-Copyleft Licences “Put The FOSS Community At Risk Of Collapse”
by Lawrence D'Oliveiro 12 Nov '15

12 Nov '15

HP’s CTO Martin Fink gave the closing keynote at the recent LinuxCon Europe conference. He argued that the proliferation of open-source software licences is (once again) having a bad effect on the health of software projects <http://lwn.net/Articles/660428/>. That much would not be so controversial, except he also claims that the use of non-copyleft “permissive” licences is adding to the problem. He justifies his argument thus: The Apache 2.0 license is currently the most widely used "permissive" license. But the thing that developers overlook when adopting it, he said, is that by using Apache they are also making a choice about how much work they will have to put into building any sort of community around the project. If you look at Apache-licensed projects, he noted, "you'll find that they are very top-heavy with 'governance' structures." Technical committees, working groups, and various boards, he said, are needed to make such projects function. But if you look at copyleft projects, he added, you find that those structures simply are not needed. The difference stems from the fact that in Apache-licensed projects, "you've always got people who are trying to go off and do their own proprietary thing." That makes their contributions to the open-source project difficult to integrate and often at odds with other participants. In a copyleft project, such as the kernel, "there is no incentive to try and carve out your own little area." As a result, contributors just do their work and the project advances. Certainly this statement of his is beyond dispute: “Copyleft is a simple, good thing: share and share alike.”

1 0

Multics vs Unix
by Lawrence D'Oliveiro 12 Nov '15

12 Nov '15

I’ve been reading the introductory “Multics Concepts and Utilization” book <http://bitsavers.trailing-edge.com/pdf/honeywell/multics/F01_multicsIntroCo…> over at Bitsavers. Multics (the “MULTiplexed Information and Computing Service”) was, for its time, an extremely ambitious operating system project. It was first introduced in 1965, in the form of a series of papers at the AFIPS Fall Joint Computer Conference of that year <http://www.computer.org/csdl/proceedings/afips/1965/5066/00/index.html>. Of course, it took far too long (7 years) to reach production quality. In that time, a small group of researchers at AT&T Bell Labs grew tired of waiting, and decided to create their own, less ambitious system, which they called “UNIX” as a tongue-in-cheek homage to “Multics”. And the rest, as they say, is history. But, nevertheless, Multics remained an influential system. There are even some present-day fans of it gathered at <http://multicians.org/>. Apparently they have got the OS booting on an emulator of the original GE 645 hardware. Though it was mostly written in a high-level language (PL/I), Multics was never a portable OS; to support its advanced virtual-memory and security features, it required special processor hardware support which was not common in those days. Even today, Multics has some features which can be considered innovative and uncommon. It may be true that, for example, SELinux can match all of its security capabilities and more. But some aspects of its file-protection system seem, to me, to make sharing of data between users a bit easier than your typical Linux/POSIX-type system. For a start, there seems to be no concept of file “ownership” as such. Or even of POSIX-style file protection modes (read/write/execute for owner/group/world). Instead, all file and directory access is controlled via access-control lists (ACLs). Directories have a permission called “modify”, which effectively gives a matching entity (user, group, process) owner-type rights over that directory; except that more than one entity can have that permission at once. Thus, a group of users working on a common project can all be given this “modify” access to a shared directory for that project, allowing them all to put data there, read it back again, control access to it, delete it etc on a completely equal basis. Contrast this with POSIX/Linux, where every file has to have exactly one owner; even if they create that file in a shared directory, it still gives the creating user a special status over that file, that others with write access to the containing directory do not have. (Multics also offers a separate “append” permission, that allows the possessor to create an item in a directory, without having the ability to remove an item once it’s there.) One radical idea introduced in Unix was its profligate use of multiple processes. Every new command you executed (except for the ones built into the shell) required the creation of a new process, often several processes. Other OSes tended to look askance at this; it seemed somehow wasteful, perhaps even sinful to spawn so many processes so readily and discard them so casually. The more conventional approach was to create a single process at user login, and execute nearly all commands within the context of that. There were special commands for explicitly creating additional processes (e.g. for background command execution), but such process creation did not simply happen as a matter of course. Gradually, over time, the limitations of the single-process approach became too much to ignore, and the versatility of the Unix approach won over (nearly) everybody. Multics, however, is of the old school. More than that, the process even preserves global state, including static storage, in-between runs of programs, and this applies across different programs, not just reruns of the same one. For example, in FORTRAN, there is the concept of a “common block”. If you run two different programs that both refer to the same common block, then the second one will see values left in the block by the first one. To completely reinitialize everything, you need to invoke the “new_proc” command, which effectively deletes your process and gives you a fresh one. One common irritation I find on POSIX/Linux systems is the convention that every directory has to have an entry called “.”, pointing to itself, and one called “..”, pointing to its parent. This way these names can be used in relative pathnames to reach any point in the directory hierarchy. But surely it is unnecessary to have explicit entries for these names cluttering up every directory; why not just build their recognition as a special case into the pathname-parsing logic in the kernel, once and for all? That way, directory-traversal routines in user programs don’t have to be specially coded to look for, and skip these entries, every single time. Multics doesn’t seem to have this problem. An absolute pathname begins with “>” (which is the separator for pathname components, equivalent to POSIX “/”), while a relative pathname doesn’t. Furthermore, a relative pathname can begin with one or more “<” characters, indicating the corresponding number of steps up from the current working directory. Unlike POSIX “..”, you can’t have “<” characters in the middle of the pathname, which is probably not a big loss. It is interesting to see other features which are nearly, but not quite, the same as, corresponding features in Unix. For example, there is a search path for executables, to save you typing the entire pathname to run the program. However, this does not seem as flexible as the $PATH environment-variable convention observed by Unix/POSIX shells. In particular, it does not seem possible to remove the current directory from the search path, which we now know can be a security risk. Another one is the concept of “active functions” and “active strings”. These allow you to perform substitutions of dynamically-computed values into a command line. However, they are not as general as the Unix/POSIX concept of “command substitution”, where an entire shell command can supply its output to be interpolated into another command. Instead of having a completely separate vocabulary of “active functions” which can only be used for such substitutions, Unix/POSIX unifies this with the standard set of commands, any of which can be used in this way. There are other features of Multics that others more familiar with it might want to see mentioned (the single-level store concept, where “everything is a memory segment”, versus Unix “everything is a file”? I/O redirection based on “switches”—symbolic references to files, versus Unix integer “file descriptors”?). But then, this long-winded essay would become even longer-winded :). So if you are interested in this particular piece of computing history, feel free to follow up the links above. In summary, Multics is very much a museum piece, not something you would want to use today for regular work—not in its original form. But I think there are still one or two ideas there that we could usefully copy and adapt to a present-day OS, particularly a versatile one like Linux.

1 1

Does The TPP Allow Prohibition Of The GPL?
by Lawrence D'Oliveiro 12 Nov '15

12 Nov '15

Some are suggesting that article 14.17 of the TPP, which begins “No Party shall require the transfer of, or access to, source code of software owned by a person of another Party...”, could be interpreted to override the requirement of the GPL to provide source code. <http://lwn.net/Articles/663817/>

1 0

File-encrypting ransomware starts targeting Linux Web servers
by Peter Reutemann 12 Nov '15

12 Nov '15

"Malware researchers from Russian antivirus vendor Doctor Web have recently discovered a new malware program for Linux-based systems that they've dubbed Linux.Encoder.1." -- source: http://www.linuxtoday.com/security/file-encrypting-ransomware-starts-target… Cheers, Peter -- Peter Reutemann Dept. of Computer Science University of Waikato, NZ +64 (7) 858-5174 http://www.cms.waikato.ac.nz/~fracpete/ http://www.data-mining.co.nz/

3 3

Unhashable: Why Fingerprints Are Weaker Security Than Passwords
by Peter Reutemann 11 Nov '15

11 Nov '15

"Fingerprints aren't terribly secure; you leave them on almost everything you touch. Many people won't realize that fingerprints can be captured and reproduced from casual photographs. It's actually worse than that. The very method with which fingerprints are stored is much weaker than passwords. Fingerprints cannot be hashed. By their very nature, each read of your fingerprint will be a little different, which breaks the hashing method. They can only be stored using encryption, which requires the same master password each time a new print read is compared to the stored key — a much weaker method than salted hashes. This more easily opens fingerprint credentials up to theft and brute forcing." -- source: http://it.slashdot.org/story/15/11/10/228223 Cheers, Peter -- Peter Reutemann Dept. of Computer Science University of Waikato, NZ +64 (7) 858-5174 http://www.cms.waikato.ac.nz/~fracpete/ http://www.data-mining.co.nz/

3 5

SUSE Leap reviewed
by Ian Young 10 Nov '15

10 Nov '15

Thanks for the interesting review. But you didn't say whether NetworkManager was functional. Just joshing :) I'm going to assume it does work because lightning couldn't strike twice right? And you didn't mention Fluxbox. I seem to recall it was once an option. Or am I thinking of FVWM?

1 0

OpenSUSE Leap 42.1 Released
by Peter Reutemann 09 Nov '15

09 Nov '15

"In what they're calling the first "hybrid" distribution release, the openSUSE project have announced the availability of openSUSE Leap 42.1. Built on a core of SUSE Linux Enterprise 12 SP1 packages but including an up-to-date userspace (KDE Plasma 5.4.2, GNOME 3.16, and many other DEs), Leap aims to provide a stable middle ground between enterprise releases which are quickly out of date, and the sometimes unstable community distros. DVD/USB or Network Install ISOs are available for download now. For those who do prefer the bleeding edge, the openSUSE Tumbleweed rolling-release distribution is also available." -- source: http://linux.slashdot.org/story/15/11/05/0246248 Sounds like an interesting concept... Cheers, Peter -- Peter Reutemann Dept. of Computer Science University of Waikato, NZ +64 (7) 858-5174 http://www.cms.waikato.ac.nz/~fracpete/ http://www.data-mining.co.nz/

2 1