SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Cinnamon would be nice, I really love it and if it were in Slackware, I don't have to start a saga every time Gnome launches a new version... Now with the 3.8 as far as I am with the cinnamon installation process, I see I will not be able to bypass systemd. and that may suck at the end... :-s
Click here to see the post LQ members have rated as the most helpful post in this thread.
I'll admit I didn't read all two years worth of threads, but what I'd like is a new "o" top level menu item with office packages in it, so I can pick one (or two). I tried doing this myself, but I couldn't get it to work. I need Koffice to open my old files, and LibreOffice to make new files.
Dump is rarely an integral part of any distribution I have ever encountered but I understand you point. Back in my early days on Slackware I was also of the same idea. In those days I could not source a dump package for Slackware; and somehow that (perhaps reluctantly) forced me to learn everything about Slackware's package management, slackbuilds and so on. It had some mistakes, but that SlackBuild introduced a whole new world for me, that probably would not have been possible on Debian or any other popular distribution. You can read about my noob frustrations, misconceptions and rants here: http://www.linuxquestions.org/questi...ackage-679969/
However I do agree that it is a useful tool, even if it is now outdated and possibly outwitted by bacula, burp, etc.
Dump is rarely an integral part of any distribution I have ever encountered but I understand you point.
Dump is part of every real Unix system out there. For a reason.
It's even already part of Slackware, but only the XFS version of it (xfsdump/xfsrestore). The libext2fs version is not outdated, it supports the current incarnation of Ext4 with every feature of it and just works great for the sole purpose it was designed for. I don't understand why it's not part of e2fsprogs.
Bacula has a complete different scope. And burp is not needed, because Slackware is already well-equipped with tools for file-based duplication.
And burp is not needed, because Slackware is already well-equipped with tools for file-based duplication.
I might be misunderstanding that one - but as somebody who discovered and started to use burp only recently after looking for years for a software of its capabilities, I'm not sure Slackware (or any other distro) has similar tools already included. Burp is not just a file-based duplication tool. Among other use case scenarios, Burp is perfectly suited for automatically backing up laptops/mobile systems which connect and disconnect from the backup server in an unpredictable manner. Burp has the following features which I haven't discovered in any other software (all of them together, that is):
1. The clients don't have any open ports waiting for the server to contact them - because it is the clients which contact the server. This is good from a security point of view - as the clients (laptops) connect to various other networks of various levels of trust - no port open on machines which frequently leave the home network is a plus.
2. The clients connect periodically to the server trying to initiated a backup (every 20 minutes by default) - but it is the server end which determines if a backup will be allowed, based on when the last full backup was completed.
3. Interrupted backups are resumed from where they last stopped - with file level granularity at the moment - but work is being done so that interrupted backups of large files can be resumed from the point in file where it was interrupted.
3. Bandwidth limits can be specified at both the server and client end - to avoid interference with regular network use.
4. Many options can be specified per client, but pushed from the server.
5. The connections are protected with SSL, with certificates, keys and CA being either setup manually or by scripts (included) when Burp is first started.
6. The server end can email alerts on success or on failure, which can be set overall or per client.
7. It can keep files in the backup archive as a normal file archive - no single file backup archive which is a nightmare to recover if it becomes corrupted.
8. It is much simpler to configure and operate than something like Bacula.
9. There are clients for Linux and Windows (and some effort on the way to have one running on OSX as well).
10. The Windows client supports VSS.
11. It can run custom scripts before and after backups, on a per client basis - which can be used to either prepare for the backup, check the backup, or prevent/allow the backup based on custom criteria.
I haven't found the above combination of features on any other backup solution I've tried so far.
I might be misunderstanding that one - but as somebody who discovered and started to use burp only recently after looking for years for a software of its capabilities, I'm not sure Slackware (or any other distro) has similar tools already included. Burp is not just a file-based duplication tool. Among other use case scenarios, Burp is perfectly suited for automatically backing up laptops/mobile systems which connect and disconnect from the backup server in an unpredictable manner. Burp has the following features which I haven't discovered in any other software (all of them together, that is)
Looks nice as one of the many file-duplication tools. But it doesn't work with tape.
It can keep files in the backup archive as a normal file archive - no single file backup archive which is a nightmare to recover if it becomes corrupted.
They're kept in one file (or tape), so you can securely wipe old backup sets. From a data security standpoint, these hard-linked "snapshots" don't look very smart...
Originally Posted by ChrisAbela
Just out of curiosity, how many real Unix system did you find out there? Is BSD one of them? I suspect that BSD does not use ext filesystems.
One may discuss what the term real Unix means, if it applies to FreeBSD (or another BSD distributions, or subset thereof), whether Linux distributions are or should be real Unix. Actually I would not be too surprised that someone here might propose the argument that a real Unix would try to converge on Slackware. Others might even argue that those searching for a real Unix, ought to look elsewhere. However, since I had asked, I think that it is fair and proper to declare that I checked and confirmed that FreeBSD does include dump in their installations (i.e. not as a port).
Last edited by ChrisAbela; 04-07-2013 at 03:20 PM.
Distribution: Slint64-14.2 on Lenovo Thinkpad W520
Originally Posted by ChrisAbela
One may discuss what the term real Unix means
No. UNIX is very clearly defined as being compliant to this specification.
Very few operating systems, if any, claim that they are true UNIXes, partly because being certified would cost them a lot of money (which is very understandable IMO, considering the amount of work needed to check all the clauses of the specification)
And AFAIK Slackware Linux, in particular, do not pretend to be POSIX compliant (the aforementioned standard is a joint one for UNIX/POSIX).
This being said, in a lot of fields that practically matters, Slackware *can* be used in a POSIX compliant way.
This is the case for instance of BASH, which is the most used shell in Slackware and *can* run in POSIX compliant mode.
And if I understand well POSIX doesn't preclude extensions.
For instance the specification defines only following internationalization variables:
LANG, LC_ALL, LC_COLLATE, LC_CTYPE, LC_MESSAGES, LC_MONETARY, LC_TIME, NLSPATH,
but the GNU gettext suite adds LANGUAGE.
As long as the former are used as intended, I don't think that using LANGUAGE in addition make the system non-POSIX or non-UNIX.
I may be wrong, though, and stay open to the discussion
PS Whether Linux distributions should be real UNIX is up to their creators.
I see two advantage of *using* a close to UNIX distribution:
(2) access to a very worthwhile documentation.
About (2): for instance I feel that the chapter of the documentation which defines the Shell Command Language is a lot easier to understand than BASH's manual. Maybe because English is not my native language...
PPS No systemd flame war intended.
Last edited by Didier Spaier; 04-07-2013 at 04:10 PM.
Reason: PS and PPS added
FreeBSD doesn't need to be certified, it's based on the original Unix code from Berkeley, that's why they had a lawsuit in the first place.
Sorry but that is completely wrong. That lawsuit was a Copyright lawsuit and had nothing to do with what the product was called, which would have been a Trademark issue. Similarly the crap that New SCO tried to pull was also about copyrights, hence why the fact that Linux is called Linux had zero impact on New SCO's bogus claims. You are marking the mistake of mixing up the various types of 'so called' intellectual property.
Source code does not define what is called UNIX, the UNIX trademark holder does. For the same reason I not could sell hamburgers I produced, 'Big Macs' (even if I used the exact 'Big Mac' recipe [think source code]) without the permission of McDonalds. Likewise an OS cannot be called UNIX without the permission of The Open Group (the current UNIX trademark holder). They get to make up the rules and in this case they give permission based on certification, which involves conforming to a defined standard ('The Single UNIX Specification') and then paying them money to check that your product confirms. If you don't conform (or even if you do conform but don't pay the money) you aren't UNIX. In the hamburger word this is like me paying McDonald's for franchise rights, thus allowing me to call my burgers Big Macs. This means that MacOS and Solaris are UNIX but FreeBSD and 'Solaris Express' (who respectively have some code shared with the previous two) are not UNIX, since neither has been certified.
If you want a non-burger example you need look no further than CentOS. CentOS does not get to call their product Red Hat Linux and in fact they take great pains to avoid doing so (and thus infringing the Red Hat's trademark). The fact that they use exactly the same source code does not change the situation one iota as Trademark Law does not care about source code similarity.
One of the Open Group's websites (UNIX.org) has page about the Flavors of UNIX, which clearly hasn't been updated in years, nonetheless it includes an interesting example to ponder, with regards to 'What about Windows® NT?' (is it UNIX)
Microsoft® Windows NT was developed as a completely new, state of the art, 32 bit operating system. As such, it has no connection with the UNIX system source code. However, market demand for POSIX.1 , POSIX.2 has led to developments by several companies of add-ons that provide partial functionality. Should the functionality meet the requirements of the UNIX brand then indeed it could become a registered UNIX system.