Welcome to the Linux Foundation Forum!
Whats the best OS for us
enwhaccount
Posts: 2
in Applications
A local chapter of Habitat for Humanity was given a computer without an OS. We want to make a slide show presentation in our window for people to see what we do on two different monitors. What would the best OS we could download for this and what would be the best program on the OS to do this?
Thanks
0
Comments
-
Ubuntu or Mint are great distros for first timers and OpenOffice Impress would probably be the best app to do a slide show.
http://www.openoffice.org/product/impress.html
Ubuntu and Mint are the easiest to install, especially if there is no operating system on the computer. Check out the link I gave you above, the application is free, and, if you want to experiment with it, there is even a Windows version if you don't have a Linux computer already set up.
BTW - If you are asking if the two different monitors can show 2 different displays, instead of a single presentation across 2 monitors, that's a bit more difficult, but probably could be done with a little bit of configuration.0 -
We are doing the same display on two different monitors. I have the cable for it. I also forgot to mention its an old computer. I has millennium on it for goodness sake. I dont really know the spec but will ubuntu work with that probably? Or do I need some really old version or will a live disk be able to do the display?0
-
enwhaccount wrote:I also forgot to mention its an old computer. I has millennium on it for goodness sake. I dont really know the spec but will ubuntu work with that probably? Or do I need some really old version or will a live disk be able to do the display?
According to the official system requirements, they recommend the following specs for an Ubuntu desktop installation:[ul][li]1 GHz x86 processor[/li][li]512 MiB of system memory (RAM)[/li][li]5 GB of disk space[/li][li]Graphics card and monitor capable of 1024x768[/li][/ul]
They also have a version called Xubuntu, which is tailored for older systems:[ul][li]256 MiB of system memory (RAM)[/li][li]2 GB of disk space[/li][li]Graphics card and monitor capable of 800x600 resolution[/li][/ul]
If your computer is even older, you could try Linux distributions like Puppy Linux instead:Puppy has been tested on a very old machines but the best results for the standard release of Puppy Linux to run at a reasonable pace have been achieved with the following:
CPU : Pentium 166MMX
RAM : 128 MB physical RAM for releases since version 1.0.2 or failing that a Linux swap file and/or swap partition is required for all included applications to run; 64 MB for releases previous to 1.0.2
Hard Drive : Optional
CDROM : 20x and up0 -
I think knoppix or DSL will do a great job. But if you want to have good graphics then go with fedora or Mandriva, they are easy to use in the live cd mode0
-
DSL worked pretty well on an old 486 DX20
-
Please see eBay to max out your RAM (probably PC133, needing 2X256), then go to http://linux.softpedia.com/progDownload/MEPIS-AntiX-Download-27857.html and download.
This Linux distro is amazing on lod machines and with access to Debian and sidux (and other) repositories, you will hav no trouble upgrading software, including OpenOffice. You will definitely need the most RAM your motherboard will support, however.
To find this out, go to SystemRescueCD (http://sourceforge.net/projects/systemrescuecd/files/) and download version 1.3.4.
It is a LiveCD and has a utility that tells one all that is needed about Hardware used.
Best wishes and my the Creator bless your efforts!0 -
I agree with GoinEasy9, Ubuntu is the easiest to install on any computer, even with the latest hardware. Mint, is another flavor of Ubuntu with a flashy GUI that they've modified while Ubuntu keeps theirs simple.
Also, Ubuntu uses the SUDO option (rootless) commands to prevent hackers from attempting to break in the system. root is present but deactivated. Never reactivate it.0 -
Maarek Stele wrote:
Also, Ubuntu uses the SUDO option (rootless) commands to prevent hackers from attempting to break in the system. root is present but deactivated. Never reactivate it.[/quote]
Why so?0 -
marc wrote:Maarek Stele wrote:
Also, Ubuntu uses the SUDO option (rootless) commands to prevent hackers from attempting to break in the system. root is present but deactivated. Never reactivate it.
Why so?[/quote]
First reason as I've seen online and from my server logs, root is the primary account automated scripts try to break in through. Before adding additional security measures to block these scripts and free up bandwidth, my server logs were in the 10s of thousands with these types of hits. Sure I'm using SSH which Greatly slows down the automation of the attack, but the whole findings end up annoying, I would trace hits from Guatemala, China, Russia, Middle East, and even parts of the US. And that's about it. Nothing more I can do in return without repercussions.
The Second part of not activating the root user is simple. If you want to be in the command line as "the" admin, just type su. you'll be at a # sign after the password and you won't need the sudo option for the server maintenance you are preforming.0 -
I differ in my opinion, sudo represents a potential issue by allowing attackers to potentially access root rights from a standard user account, which may have a weak password. I think it is better practice to keep the root account, remove sudo rights except for specific actions and secure root with a difficult password. As for ssh that should be restricted to not allow root login and limit retries or only allow root ssh access via a key file.0
-
Good tips, moderator! I believe I had what you refer to happen to me. As such, should one goes with any ubuntu flavor to access the web, I would recomment immediately installing Bastille along with it.0
-
Maarek Stele wrote:First reason as I've seen online and from my server logs, root is the primary account automated scripts try to break in through. Before adding additional security measures to block these scripts and free up bandwidth, my server logs were in the 10s of thousands with these types of hits. Sure I'm using SSH which Greatly slows down the automation of the attack, but the whole findings end up annoying, I would trace hits from Guatemala, China, Russia, Middle East, and even parts of the US. And that's about it. Nothing more I can do in return without repercussions.
The Second part of not activating the root user is simple. If you want to be in the command line as "the" admin, just type su. you'll be at a # sign after the password and you won't need the sudo option for the server maintenance you are preforming.
I totally disagree. If you feel unsafe on your server for the root user, just disable the remote login as root (besides, that is the right thing to do).
And about the "su" command, you can't do that on Ubuntu as the root user is disabled! There is no password for it
First thing I do on sudo based systems:sudo passwd
To get the root user back.
Using sudo is getting another program with the suid bit which is a security flaw as well. The less programs you have with that bit the better.
What else? Using sudo is getting the admin security to a user's password level... safer than having a safe password for root? I guess not
Naaaahh, using sudo is a bad idea security wise IMHO0 -
sudo can only be used by an admin level user. Standard users do not have permission to use the sudo command unless permitted via their own password. Also, if you have a poor password, then it's your own fault. Also, su again, only for the admin user to temporary activate the root user for multiple commands. Once the terminal session ends, so does that option.
Sudo allows flexibilty for standard users. Because you can edit he sudo file for that user and make them a "power user" rather then an admin who is capable of venturing everywhere on the system. The sudo option also tracks the user since you won't share the root account with anyone else for security purposes. the initial user is the admin which has access to the sudo command. All subsequent users do not have access to sudo unless granted by the admin. It's all about perception
http://manpages.ubuntu.com/manpages/karmic/en/man8/sudo.8.html
Frankly if you are used to root, then use that. years ago I've used Slackware on older 486 computers. To me I'm rather pleased with Ubuntu's progress over the years.0 -
Nice explanation Maarek,
I mean don't get me wrong sudo is extremely useful when it is used correctly. And Ubuntu's method of using sudo for the for the admin and default user is both good and bad:
Pros:
it keeps the users from running everything as root
The default unconfigured installation has security that is accessible to normal users
Cons:
Some users don't really understand why they are using sudo, so they end up using it for all command line commands.
If the user does not practice proper security the system is quite exploitable
The default user which is normally the admin has full rights that can be exploited by anyone logged into the account.
It all comes down to a simple rule, the system is only as good as the admin, if the admin does not know what they are doing then you can only do so much to force integrity and security.0 -
Still can't see the point of using sudo. I would prefer using "su" not just to login as root but to run a command as sudo does. Besides, with "su" you can run any command as any user/group you want...
I fail to see the usefulness in sudo as "su" does exactly the same (as far as I know). Would you point me to something that "sudo" does that is different from "su"?
And, still, you rely on a *user's password for security!!! I agree that is not every user on the system but a few granted but I still believe is safer to have a root admin for doing "admin staff".
Marc
PS:love this healthy discussions!!!0 -
sudo can be useful if you edit the sudoers file to give rights to specific command such as changing specific user's passwords, modifying network connection, etc... but using it to give someone full rights to the admin console is some type of security oer letting them run everything from a root gui login, but not enough to call the system trustworthy.0
-
marc wrote:I fail to see the usefulness in sudo as "su" does exactly the same (as far as I know). Would you point me to something that "sudo" does that is different from "su"?
That's your perspective of being an admin for the system. If my boss said we are using DISTRO X (that uses root), I won't mind one bit. To me, The su/root option is like CAPS LOCK, once you have it on and start typing, you need to delete what you typed to correct the problem, and can be fatal in some cases. For example, while viewing a system file as su/root, you might type something or hit a key deleting a line withing vi. sure, you can always q! out, but you might type w first out of habit and permanently change the file. The sudo option, or lack of it allows you to view the file as an admin and not worry about making any changes.
Even with root in systems typing su will switch over to the root user. I guess my point is that you cannot login as root itself on a system that strongly emphasizes on sudoers unless you set a password for root. Root is present & active, just check the process list. Root is running the system, sudoers just help maintain it.0 -
mfillpot wrote:I differ in my opinion, sudo represents a potential issue by allowing attackers to potentially access root rights from a standard user account, which may have a weak password. I think it is better practice to keep the root account, remove sudo rights except for specific actions and secure root with a difficult password. As for ssh that should be restricted to not allow root login and limit retries or only allow root ssh access via a key file.
sudo sux0 -
I personally use both su and sudo, but for different tasks.
Sure, they overlap in many ways; sudo -s can give you a root shell (like su), and su -c lets you run a single command as root (like sudo). Sudo can also be configured to request the root password instead of the user password (check man sudoers). As pointed out in previous posts, a properly configured system can be about equally secure with both approaches.
What I like about sudo though, is that the flexibility you get through the /etc/sudoers file. For instance, this entry is taken from my sudoers file:jabirali hermes=NOPASSWD: /usr/bin/acpitool -s
That line lets the user jabirali from the host hermes (the local hostname) run the command /usr/bin/acpitool -s (suspend the computer) with root privileges - without entering a password. If the alternative is e.g. giving SUID-rights to /usr/bin/acpitool, this approach has many advantages:
[ul][li]You can restrict what arguments are passed to the program; invoking acpitool in any other way than the exact wording specified in /etc/sudoers will not work.[/li][li]One application with SUID-rights (sudo) is likely more secure than a lot of SUID-apps scattered throughout your filesystem.[/li][li]You can give certain users (e.g. a special group) rights to execute a handful of commands, without either giving them the root-password or modifying the rights of the files.[/li][li]One file is easier to manage in the long run (in my opinion) than scattered SUID rights.[/li][/ul]
Another potentially useful example could be to give a certain user the ability to su to another user by providing his own password, this time from all hosts:jabirali ALL=/bin/su guest
(This allows jabirali to run /bin/su guest as root after providing his own password)
If you still want to use only su to run anything but selected tasks (like the examples above), that should also be easy to configure. E.g. the default /etc/sudoers on ArchLinux contained this line:%wheel ALL=(ALL) ALL
That gives everyone in the group wheel permissions to run anything as root, given that they provide their own password. You can just comment out that line! Or perhaps more useful: modify it to require the root password (search for rootpw in the sudoers manpage).0 -
All this sudo staff is fantastic but I'll stay with my opinion: admin staff should be done by the admin and not by any user.
I guess it's about choice, isn't it?
Regards0 -
I've always thought of sudo as a security risk, and, yes I've heard all the arguments to the contrary. But on my machines, the admin (me) does the administrative work. I don't want to extend any kind of permissions to anyone, even if it is temporary. So, sudo ... no like it, don't want it, don't use it.sudo sux0
-
I completely agree with you.0
-
I think I am going to give Debian a try!0
-
Once, a long time ago, on a POSIX real-time operating system, I was logged in as root with "su -", and had cd'd to /. Some time later, in a distracted minute, thinking I was still running in a user, not root, shell, I executed the command "rm -rf *"... Hilarity ensued! Doh! One thing about sudo, is that this won't happen, unless of course you have executed "sudo su"! :-) So, for my own purposes, I am ambivalent about either approach, although I do configure my Ubuntu systems to allow root logins; however, I do use a strong password for the root account - you need a good Sanskrit dictionary, along with some physics to derive it... I expect that the universe will reach maximum entropy before anyone can guess it!
0
Categories
- All Categories
- 167 LFX Mentorship
- 219 LFX Mentorship: Linux Kernel
- 795 Linux Foundation IT Professional Programs
- 355 Cloud Engineer IT Professional Program
- 179 Advanced Cloud Engineer IT Professional Program
- 82 DevOps Engineer IT Professional Program
- 127 Cloud Native Developer IT Professional Program
- 112 Express Training Courses
- 112 Express Courses - Discussion Forum
- 6.2K Training Courses
- 48 LFC110 Class Forum - Discontinued
- 17 LFC131 Class Forum
- 35 LFD102 Class Forum
- 227 LFD103 Class Forum
- 14 LFD110 Class Forum
- 39 LFD121 Class Forum
- 15 LFD133 Class Forum
- 7 LFD134 Class Forum
- 17 LFD137 Class Forum
- 63 LFD201 Class Forum
- 3 LFD210 Class Forum
- 5 LFD210-CN Class Forum
- 2 LFD213 Class Forum - Discontinued
- 128 LFD232 Class Forum - Discontinued
- 1 LFD233 Class Forum
- 2 LFD237 Class Forum
- 23 LFD254 Class Forum
- 697 LFD259 Class Forum
- 109 LFD272 Class Forum
- 3 LFD272-JP クラス フォーラム
- 10 LFD273 Class Forum
- 152 LFS101 Class Forum
- 1 LFS111 Class Forum
- 1 LFS112 Class Forum
- 1 LFS116 Class Forum
- 1 LFS118 Class Forum
- LFS120 Class Forum
- 7 LFS142 Class Forum
- 7 LFS144 Class Forum
- 3 LFS145 Class Forum
- 1 LFS146 Class Forum
- 3 LFS147 Class Forum
- 1 LFS148 Class Forum
- 15 LFS151 Class Forum
- 1 LFS157 Class Forum
- 33 LFS158 Class Forum
- 8 LFS162 Class Forum
- 1 LFS166 Class Forum
- 1 LFS167 Class Forum
- 3 LFS170 Class Forum
- 2 LFS171 Class Forum
- 1 LFS178 Class Forum
- 1 LFS180 Class Forum
- 1 LFS182 Class Forum
- 1 LFS183 Class Forum
- 29 LFS200 Class Forum
- 736 LFS201 Class Forum - Discontinued
- 2 LFS201-JP クラス フォーラム
- 14 LFS203 Class Forum
- 102 LFS207 Class Forum
- 1 LFS207-DE-Klassenforum
- 1 LFS207-JP クラス フォーラム
- 301 LFS211 Class Forum
- 55 LFS216 Class Forum
- 48 LFS241 Class Forum
- 42 LFS242 Class Forum
- 37 LFS243 Class Forum
- 15 LFS244 Class Forum
- LFS245 Class Forum
- LFS246 Class Forum
- 50 LFS250 Class Forum
- 1 LFS250-JP クラス フォーラム
- LFS251 Class Forum
- 154 LFS253 Class Forum
- LFS254 Class Forum
- LFS255 Class Forum
- 5 LFS256 Class Forum
- 1 LFS257 Class Forum
- 1.3K LFS258 Class Forum
- 10 LFS258-JP クラス フォーラム
- 111 LFS260 Class Forum
- 159 LFS261 Class Forum
- 41 LFS262 Class Forum
- 82 LFS263 Class Forum - Discontinued
- 15 LFS264 Class Forum - Discontinued
- 11 LFS266 Class Forum - Discontinued
- 20 LFS267 Class Forum
- 24 LFS268 Class Forum
- 29 LFS269 Class Forum
- 1 LFS270 Class Forum
- 199 LFS272 Class Forum
- 1 LFS272-JP クラス フォーラム
- LFS274 Class Forum
- 3 LFS281 Class Forum
- 9 LFW111 Class Forum
- 260 LFW211 Class Forum
- 182 LFW212 Class Forum
- 13 SKF100 Class Forum
- 1 SKF200 Class Forum
- 1 SKF201 Class Forum
- 782 Hardware
- 198 Drivers
- 68 I/O Devices
- 37 Monitors
- 96 Multimedia
- 174 Networking
- 91 Printers & Scanners
- 83 Storage
- 743 Linux Distributions
- 80 Debian
- 67 Fedora
- 15 Linux Mint
- 13 Mageia
- 23 openSUSE
- 143 Red Hat Enterprise
- 31 Slackware
- 13 SUSE Enterprise
- 348 Ubuntu
- 461 Linux System Administration
- 39 Cloud Computing
- 70 Command Line/Scripting
- Github systems admin projects
- 90 Linux Security
- 77 Network Management
- 101 System Management
- 46 Web Management
- 64 Mobile Computing
- 17 Android
- 34 Development
- 1.2K New to Linux
- 1K Getting Started with Linux
- 371 Off Topic
- 114 Introductions
- 174 Small Talk
- 19 Study Material
- 507 Programming and Development
- 285 Kernel Development
- 204 Software Development
- 1.8K Software
- 211 Applications
- 180 Command Line
- 3 Compiling/Installing
- 405 Games
- 309 Installation
- 97 All In Program
- 97 All In Forum
Upcoming Training
-
August 20, 2018
Kubernetes Administration (LFS458)
-
August 20, 2018
Linux System Administration (LFS301)
-
August 27, 2018
Open Source Virtualization (LFS462)
-
August 27, 2018
Linux Kernel Debugging and Security (LFD440)