2008-10-17, 04:29 | Link #742 |
Founder, Sprocket Hole
Fansubber
Join Date: Apr 2004
Location: Fresno or Sacramento, CA
Age: 56
|
Now for the really insane: I'm looking at installing Ubuntu on my recently-decommissioned UltraSPARC-based Ultra 5 workstation! (It'll be an older version as it appears to have been discontinued for sparc64.) It used to be my former job's mailserver which ran Solaris 2.6 and Post.Office. When shop closed, I inherited the machine along with the accounts that machine served (I have since migrated that service over to a FreeBSD machine which holds their websites when one of the machine's hard drives started making really bad bearing noises). Now, it's just an extra machine I have lying around. Right now, it's running FreeBSD/sparc64 7.0-RELEASE.
Has anyone played with Ubuntu on non-x86(-64) hardware? Nowadays, it seems to ONLY be available for x86(-64) machines. --Ian. |
2008-10-22, 17:53 | Link #745 | |
Geek
|
Quote:
I played with an older version of Ubuntu for PPC on an older iBook. Hardware support was unsurprisingly pretty terrible. The only SPARC machine I have is running Solaris 10. |
|
2008-10-24, 22:07 | Link #746 | ||
Founder, Sprocket Hole
Fansubber
Join Date: Apr 2004
Location: Fresno or Sacramento, CA
Age: 56
|
Quote:
Quote:
--Ian. |
||
2008-10-25, 09:59 | Link #747 |
Gregory House
IT Support
|
Okay, I upgraded to Intrepid yesterday, and now I'm struggling with KDE 4. I know that if I use it enough I'll get used to it, but there are so many things... so buggy and unstable. It's definitely not mature enough yet.
I miss KDE 3. I wonder why Canonical decided not to support it anymore starting 8.10, considering KDE 4.2 hasn't even been released.
__________________
|
2008-10-25, 11:47 | Link #748 |
I desire Tomorrow!
Join Date: Dec 2005
Location: As far away from reality as possible
Age: 41
|
KDE4 is good, I tested 4.0, 4.1+ on the Kubuntu versions, but it's still rough around the edges. However, my preference is KDE4->GNOME->>>>>>KDE3. I absolutely hated KDE3. KDE4 IS functional enough for most things, it needs stability fixes and good Amarok 2 and K3b versions. The Kubuntu implementation was good, the Kubuntu Intrepid integration is not that good. I was hoping they'll completely drop KDE3 programs and dependencies, but instead I see Amarok 1.4 installed.
Anyway, I'll check KDE4 again on version 4.2. Right now, I'm still on Ubuntu 8.04.
__________________
|
2008-10-25, 14:02 | Link #751 |
Love Yourself
Join Date: Mar 2003
Location: Northeast USA
Age: 38
|
I have a question about security on the *NIX systems. Unless you're logged in as root or maybe an administrator account, you'll need an administrator password to modify/remove/install programs and touch core system files. This is generally seen as being a major security benefit for *NIX over traditional Windows systems.
Windows Vista attempted to change that by implementing their User Access Control scheme, which performs the same verification for high-level system access as in *nix's requirement that you type in administrator credentials - the only difference being that for UAC you simply click "allow" or "deny" (or what ever the other option was). One of the early criticisms of UAC was the fact that it would be possible for a program to mimic this window in some fashion to cause harm. Similarly, for us *nix users, when you type in your login credentials how do you know that it's going straight to the system and isn't being retained by a program for later use? Is there any way to verify (aside from not giving the password and seeing what happens), or are we to blindly trust that the programs we're using either aren't malicious or haven't been maliciously modified? This doesn't apply specifically to Ubuntu, but this thread has sort of become the Linux/Unix thread in general, so I hope you don't mind my asking this here.
__________________
|
2008-10-25, 16:07 | Link #752 | |
eyewitness
Join Date: Jan 2007
|
Quote:
Long answer: Once a hacker has gained root access somehow he can easily install a trojan to fetch the root password as well as the user passwords. It's the duty of the super user to not let that happen in the first place. And any system should run security checkers like tiger to detect anything odd. As long as the hacker doesn't understand and corrupt the security measures fast enough of course.
__________________
|
|
2008-10-25, 16:26 | Link #753 | |
Geek
|
Quote:
|
|
2008-10-25, 17:03 | Link #754 | |
AS Oji-kun
Join Date: Nov 2006
Age: 74
|
Quote:
What I don't know is how SE LInux applies to this. I'll say right now that I routinely set SELINUX to permissive (logs events, doesn't block anything) on RedHat-flavored boxes because it can be a real pain in the neck when enabled. Nevertheless I thought that, when enabled, SE Linux maintains an inventory of legitimate binaries and blocks the execution of ones not in the database. If so, that goes a long way toward preventing the accidental execution of some rogue program as an ordinary user. I may be talking out of my hat here, though. Just to answer Ledgem's question more generally, there's also the issue of protecting your login credentials when communicating with remote hosts as well. If these are hosts you maintain, you should set up a VPN to encrypt all your traffic between your local network and the remote hosts(s). I like OpenVPN for point-to-point tunnels with shared keys. It's trivial to set up and "just works." I still use SSH within the tunnels; I don't see any performance loss from the double encryption involved. If you want to comply with official US government standards, you can't use encryption beyond 256-bit AES (pretty secure against everyone except the NSA and similar agencies, I'd guess). You can have keys as long as 448 bits using Blowfish.
__________________
|
|
2008-10-25, 17:15 | Link #755 |
Love Yourself
Join Date: Mar 2003
Location: Northeast USA
Age: 38
|
In the situation I'm imagining, suppose that you're trying to install software. You'll need to enter your administrator credentials to do this. But what if the program actively stores the login and password information and either uses this for a malicious purpose or sends it to a malicious third party. I can't think of a guard against that, aside from using a firewall for the latter concern.
This isn't a question deserving a snooty response of "don't use pirated software, only use legit software from trusted sources" - companies have been compromised on numerous occasions, and it seems to be that it's realistic for source code for some respected program to be modified and unknowingly be distributed. I suppose there's nothing that can be done about that, you're forced to trust that the software is what it is and nothing more. (I except WanderingKnight to remark about how open source software is superior for this concern :P ) Seiji, what do you mean that the government standards dictate that you can't use beyond 256-bit AES - is it illegal to use higher-level encryption?
__________________
|
2008-10-25, 17:55 | Link #756 | |
AS Oji-kun
Join Date: Nov 2006
Age: 74
|
Quote:
For private communications, it probably varies considerably. I'm pretty sure most commercial encryption devices stay within the standard, but if you're rolling your own security I don't think there's any prohibition on the strength of ciphers. OpenVPN uses 448-bit Blowfish by default, for instance. For organizations like universities which have some ties to the Federal Government, I can't say what the rules might be. If you're working on a Federally-funded project you're probably officially limited to AES. For people involved in research with no Federal ties, only the university's legal department knows the answer.
__________________
|
|
2008-10-25, 18:20 | Link #757 | |
Geek
|
Quote:
Last I looked, creating SELinux policies was not fun. Not fun at all. There are domains, file labels, types, etc. that you have to deal with. The default targeted policies in RH/Fedora are mainly there to restrict what daemons may or may not do. There is a policy that can allow/deny samba from sharing home directories, one that allows/denies apache from running cgi, etc. If someone were to compromise a daemon and run code in the daemon's context it should theoretically be limited in what it can do on the system. |
|
2008-10-25, 21:39 | Link #758 | |
eyewitness
Join Date: Jan 2007
|
Quote:
You really shouldn't input passwords into closed source applications. But major f...ups also happen with legit open software from most trusted sources. I think I mentioned it already in this very thread. Not long ago there was a major bug in Debian's OpenSSL package (and consequently all Debian derivatives like Ubuntu) making crypto keys vulnerable to brute force attacks. Actually, a tender caress rather than brute force was already sufficient. Not the same as intentionally distributing a Trojan but still ... Long story short, some noob was maintaining the OpenSSL package, was bothered by some line generating a complier warning, asked the wrong people for help, and IIRC even without revealing that he was working for Debian. And finally, he then changed a second, similar line which introduced the bug that made the keys guessable. And since the code was delivered by DEBIAN nobody seems to have bothered to check it for almost two years. The morale of this particular case is twofold, I think. 1. Open source doesn't help as long as everybody assumes somebody else will probably have looked into it. 2. Debian doesn't have the manpower to properly maintain their packages and should better trust the developers. I just hope they now have at least two people to check the security relevant code they mess with.
__________________
|
|
2008-10-26, 09:08 | Link #759 |
Life's better in a harem.
Graphic Designer
Join Date: Dec 2007
Location: Oakville, Ontario, Canada
|
I have a quick question about using GParted. I recently installed Vista on a 20 GB partition that I made after my Ubuntu partition. But now that I've installed Vista, I've almost completely filled up its partition.
So my question is, can I expand my windows partition without corrupting either partition? Here's a screenshot of my partitions if it helps:
__________________
|
2008-10-26, 09:39 | Link #760 | |
Geek
|
Quote:
Someone who didn't understand the OpenSSL code they were changing broke OpenSSL in Debian. He asked on an OpenSSL mailing list before making the change and the two substantive responses received said it was fine to make the change he was asking about. He provided almost no context though so it was possible they didn't realize where in the source tree he was making the change. Then the flaw was allowed to exist for almost two years because Debian maintains their own OpenSSL patch set. This is another mistake IMO. Any patches a distro develops (that aren't specific to getting the package compiling/running on the particular distro) should attempt to be pushed upstream. If they had done that someone from OpenSSL may have figured out that this patch would introduce a big problem. |
|
Tags |
linux, ubuntu |
|
|