I'd like to give Linux a try.

[n0cmonkey]

Originally posted by: Nothinman
The last time I looked at yum it took many magnitudes longer to do things than apt does and I doubt it'll ever compare since it's done in Python and maybe the defaults have changed, but the -C (not sure if it was capital or not) was needed to make it use the local package cache.

I'll have to check it out if I boot fedora again.

 

[Nothinman]

I'll have to check it out if I boot fedora again.

I just downloaded a Xen image of FC5 to check out, we'll see how well that goes for me. =)

 

[n0cmonkey]

Originally posted by: Nothinman

I'll have to check it out if I boot fedora again.

I just downloaded a Xen image of FC5 to check out, we'll see how well that goes for me. =)

It seemed just fine to me. As far as Linux goes.

Getting VMWare to work was a little bit of a pain, but some googling helped out a lot.

The only real issue I had was getting it to triple boot with OpenBSD/amd64 and XP. It worked just fine with XP, but if I installed OpenBSD second (1. XP 2. Open 3. Fedora) Fedora would error out when moving into the partitioning section of the install. Or it would show me either a blank disk or a disk that wouldn't work unless I formatted the whole thing.

I ended up installing OpenBSD last and it worked just fine. I'm guessing Fedora didn't like the Open disklabel, not sure why though.

 

[Nothinman]

It seemed just fine to me. As far as Linux goes.

You have pretty low expectations then:

#time apt-cache search snort >/dev/null

real 0m0.762s
user 0m0.724s
sys 0m0.004s

# time yum -C search snort >/dev/null

real 0m49.904s
user 0m37.990s
sys 0m10.477s

And the times were the almost exactly same with or without the -C option.

 

[n0cmonkey]

Originally posted by: Nothinman

It seemed just fine to me. As far as Linux goes.

You have pretty low expectations then:

#time apt-cache search snort >/dev/null

real 0m0.762s
user 0m0.724s
sys 0m0.004s

# time yum -C search snort >/dev/null

real 0m49.904s
user 0m37.990s
sys 0m10.477s

And the times were the almost exactly same with or without the -C option.

I multi-task so one process taking 50 seconds more than another doesn't matter much to me. Plus, I'm not much of a tweaker these days so once things are setup there isn't a WHOLE lot of change.

 

[Brazen]

Originally posted by: Nothinman

It seemed just fine to me. As far as Linux goes.

You have pretty low expectations then:

#time apt-cache search snort >/dev/null

real 0m0.762s
user 0m0.724s
sys 0m0.004s

# time yum -C search snort >/dev/null

real 0m49.904s
user 0m37.990s
sys 0m10.477s

And the times were the almost exactly same with or without the -C option.

Your 'puter is borked.

# time yum search snort >/dev/null

real 0m11.947s
user 0m7.899s
sys 0m0.792s

And this is on a rather busy CentOS server.

The only thing yum has over apt is the localinstall command and I can't even see that being useful very often.

It is.

 

[Nothinman]

Your 'puter is borked.

# time yum search snort >/dev/null

real 0m11.947s
user 0m7.899s
sys 0m0.792s

And this is on a rather busy CentOS server.

As I said it was a FC5 Xen image so it's possible the virtualized I/O slowed it down, it's hard to say since I was doing that on my home machine from work. But I seem to remember similar results when we put FC5 on a guy's notebook at work. But even if that 50s is really exaggerated 11s vs .7s is a huge difference and adds up to a huge amount of annoyance very quickly.

It is.

I suppose it could be if you're stuck with the anorexic amount of packages that FC has available in it's default repositories.

 

[n0cmonkey]

Originally posted by: Nothinman
As I said it was a FC5 Xen image so it's possible the virtualized I/O slowed it down, it's hard to say since I was doing that on my home machine from work. But I seem to remember similar results when we put FC5 on a guy's notebook at work. But even if that 50s is really exaggerated 11s vs .7s is a huge difference and adds up to a huge amount of annoyance very quickly.

Maybe you should run NetBSD instead of Linux for the Dom0 (U? I can never remember which is the host).

 

[Nothinman]

Maybe you should run NetBSD instead of Linux for the Dom0 (U? I can never remember which is the host).

That wouldn't really work since that's my home workstation and there's no way I'm taking the time to reload it and convert all of my filesystems to something NetBSD can read =)

And dom0 is the host and domU are the 'unprivileged' domains.

 

[n0cmonkey]

Originally posted by: Nothinman

Maybe you should run NetBSD instead of Linux for the Dom0 (U? I can never remember which is the host).

That wouldn't really work since that's my home workstation and there's no way I'm taking the time to reload it and convert all of my filesystems to something NetBSD can read =)

And dom0 is the host and domU are the 'unprivileged' domains.

Ah, I got it right.

But benchmarks show NetBSD is better!

 

[Nothinman]

But benchmarks show NetBSD is better!

But Xen isn't the primary function of that box and I'd have to put up with running NetBSD, so I'll pass =)

 

[n0cmonkey]

Originally posted by: Nothinman

But benchmarks show NetBSD is better!

But Xen isn't the primary function of that box and I'd have to put up with running NetBSD, so I'll pass =)

Probably a wise decision.

 

[Brazen]

Originally posted by: Nothinman

But benchmarks show NetBSD is better!

But Xen isn't the primary function of that box and I'd have to put up with running NetBSD, so I'll pass =)

BUT THINK OF THE BENCHMARKS!!!

 

[n0cmonkey]

Originally posted by: Brazen
BUT THINK OF THE BENCHMARKS!!!

It's a big deal whenever a BSD beats Linux in some arbitrary benchmark.

 

[Nothinman]

BUT THINK OF THE BENCHMARKS!!!

So far the only thing I've benchmarked is yum and I doubt switching to NetBSD can help that out =)

 

[n0cmonkey]

Originally posted by: Nothinman

BUT THINK OF THE BENCHMARKS!!!

So far the only thing I've benchmarked is yum and I doubt switching to NetBSD can help that out =)

Maybe, with its faster virtual disk access.

 

[Nothinman]

Maybe, with its faster virtual disk access.

Forgive my lack of faith in yum and python, but I really doubt it =)

 

[drag]

Yum is badly designed.

When python is used correctly it's fairly fast and has advantages over Java and Mono over memory footprint. The major trouble with it is that people use it because they don't know how to use anything else and obviously it isn't going to turn out the greatest. If python is used is major video games like Battlefront 2 and plenty of MMORPG types games and can be used to write highly complex web applications that are much more complex and much more faster then yum every will be you can't blame python for yum's problems.

It's just that you need to use it appropriately. Python is no replacement for C code were your doing a large amount of proccessing or number crunching. It doesn't come close.

Anyways yum's speed is annoying. It has numerious other issues much more important..

Like how is it when a update gets aborted you end up with 2 sets of various packages installed? It doesn't even make sense. How can you have 2 rpms of the same type with different versions installed?
I know it's suppose to be only when something goes wrong.. but every time I touch a Redhat or Fedora box there is always going to be at least a small handfull of duplicate packages installed... WTF?
And why then is there no sane way to recover from something like that? Some command to show duplicate packages, to detect them and finish upgrade.

If your doing a huge update and something goes wrong during it.. then you have a huge mess on your hands.

That's just ONE issue. There are others. The speed of execution is small potatoes compared to that. I don't care if it takes 3 minutes to do a update rather then 47 seconds or 11 seconds or 0.7 seconds as long as the stupid thing worked properly and had intellegent error handling.