![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
I used to quite like OpenSUSE. However, the other day I installed it
about 13 seperate times. Let me tell you why.
I set up a virtual machine and start installing. It takes rather a long
time to do this, by the way. Eventually the installation finishes, I go
to long in... and discover that my password isn't recognised. If I log
in as root it works, and then I discover that root is the only user
account set up on the system. (Despite the installer asking me for a
regular username and password.)
After repeating this song and dance a few times, I discover something.
During the installation process, one of the text screens that flashes
past too quickly for you to read it says (approximately) this:
*** Starting YaST...
src/module82/sub46/foo.c: malloc(1) failed. Aborting.
This in amoungst an entire screenful of other chatter, mind you.
So I try again for the 7th time, and this time I give the VM 1GB of RAM
instead of just 0.5GB. At the point where this text screen flashes past,
I now get YaST show up and tell me it's "saving user settings". And it
spends about 3 minutes doing it. AND, when the installation is finally
finished, I can actually log in, and everything works.
To sumarise, if you have less than 1GB of RAM, part of the installation
process silently dies, and the rest of the installer script carries on
anyway. There *is* an error message, but it flashes past far too fast to
see unless you're really watching like a hawk. (And how many non-geeks
would know that "malloc(1) failed" indicates a memory problem??)
Did somebody fail basic software engineering? Hello? Graceful failure?
If your product doesn't support computers with less than 1GB of RAM then
fine, fair enough. But you should at least STATE THIS, rather than just
silently continue even though part of the installation has
catastrophically failed. If this was a physical machine, I could have
wasted hours checking the CD burned correctly, testing my CD drive,
running memory checks, and so on.
How difficult would it be to detect, right at the beginning of the
installation, that the PC has only 0.5GB of RAM, and only offer
installation options which will ACTUALLY WORK WITH THIS CONFIGURATION??
(Better yet, I can't actually see anything anywhere on the OpenSUSE
website which actually states what the minimum spec is supposed to be in
the first place. I'm guessing if I select text-mode install, the minimum
spec decreases dramatically...)
Additionally: Maybe I'm just going soft in my old age. But does anybody
else here remember a time when the most touted advantage of Linux was
"it's much less of a resource hog than Windows"? I realise that RAM is
cheap these days, but a distro that won't even install unless you have
ONE GIGABYTE of RAM?? What the hell does the installer need a gig for?!
The above was using KDE. It turns out that installation fails in the
exact same way if you select GNOME instead. RAM may be cheap, but my PC
only has a finite amount of it, so I can't just hand it out to random
VMs like it's candy. Ubuntu works just fine with 0.5GB. Debian works
just fine with 0.5GB. In fact, I'm pretty sure I've installed both of
them with as little as 300MB of RAM. Hell, KNOPPIX contains everything
*including* the kitchen sink, and it only demands 128MB to work.
(Although obviously not very well.) But an installer that won't even
bother getting out of bed for less than 1024MB? Um, why??
(Again, I imagine if I ask for a minimal text-mode system rather than an
all-singing KDE setup, it probably works with a lot less. But even so...
why?)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible wrote:
> (Better yet, I can't actually see anything anywhere on the OpenSUSE
> website which actually states what the minimum spec is supposed to be in
> the first place. I'm guessing if I select text-mode install, the minimum
> spec decreases dramatically...)
Oh, wait, I found it:
http://en.opensuse.org/Sysreqs
I don't know why this isn't linked from anywhere [that I could find]. In
the end I had to resort to Google.
Also: Notice the stunning absence of OpenSUSE 11.2, the version I am
actually using.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Heh, and I almost forgot:
I got OpenSUSE to install (default KDE install). The desktop looks
pretty far-out now, but maybe I can get used to it. Anyway, I asked it
to do an online update. It started updating... I guess... but all I
could see on the screen was *literally* an empty rectangle with a square
bouncing back and forth along it. No actual progress indication, just a
bouncing square to let me know it's still doing... something.
Uh, WTF? What's useless! o_O
I found a button that says "show detailed information", but it didn't
seem to make any difference at all. Great.
Interestingly, I set up another VM with GNOME, and here doing an online
update ACTUALLY TELLS YOU what's happening. Which is just as well,
because it takes about 45 minutes to finish updating.
Still, at least this isn't Windows - you don't have to reboot. Oh, wait,
yes you do apparently. At least, you don't *have* to, they just tell you
that some updates won't completely take effect until you do.
[In fairness, I think one of the updates that went past was a kernel
update. Services and applications can be restarted, but the kernel
really, really can't.]
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible <voi### [at] dev null> wrote:
> *** Starting YaST...
> src/module82/sub46/foo.c: malloc(1) failed. Aborting.
How about making a bug report?
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible <voi### [at] dev null> wrote:
> Still, at least this isn't Windows - you don't have to reboot. Oh, wait,
> yes you do apparently. At least, you don't *have* to, they just tell you
> that some updates won't completely take effect until you do.
Linux doesn't support switching kernels on-the-fly. Not many OSes do.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Invisible <voi### [at] dev null> wrote:
>> Still, at least this isn't Windows - you don't have to reboot. Oh, wait,
>> yes you do apparently. At least, you don't *have* to, they just tell you
>> that some updates won't completely take effect until you do.
>
> Linux doesn't support switching kernels on-the-fly. Not many OSes do.
No, that's understandable.
Presumably though if the updates hadn't included changes to the kernel,
it would have just restarted a few services or whatever... Usually Linux
is quite good at that sort of thing.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Invisible <voi### [at] dev null> wrote:
>> *** Starting YaST...
>> src/module82/sub46/foo.c: malloc(1) failed. Aborting.
>
> How about making a bug report?
I'm surprised there isn't one listed already.
Of course, if I was going to do that, I'd have to sit there and freeze
the VM at the exact point where the error pops up so I can write down
precisely what it said.
And then find the bug tracker, register an account, log in, write a
description... I guess if I was committed to using OpenSUSE on a
long-term basis, it might be worth the effort. But it's not the kind of
effort you're going to expend on every product you try out.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible wrote:
> Did somebody fail basic software engineering?
Yes.
> How difficult would it be to detect,
More difficult than the guy writing the software for free felt like writing.
That's one fundamental problem with FOSS. (Altho that might start changing
given the number of people now being paid to write FOSS is outweighing the
number of people not paid to write FOSS.)
> Additionally: Maybe I'm just going soft in my old age. But does anybody
> else here remember a time when the most touted advantage of Linux was
> "it's much less of a resource hog than Windows"? I realise that RAM is
> cheap these days, but a distro that won't even install unless you have
> ONE GIGABYTE of RAM?? What the hell does the installer need a gig for?!
Don't confuse the distro with the OS. Linux installs happily in <32M (at
least on my set-top box). That a distro takes more isn't a problem, any more
than Win7 taking more memory than WinCE is.
> Services and applications can be restarted, but the kernel really, really can't.]
This is misleading too. If you're running a web server or a DB server, the
difference between restarting the services and restarting the kernel is
minimal. You're still not running while it's happening. And depending on
what component you've replaced, you very well may not have updated
everything you think you have. E.g., if you replace the PHP interpreter with
one that has security bugs fixed, you now have to restart every service
written in PHP to ensure that fix is in place. Which services are they? You
can't tell. At least with Windows locking executables that are running, you
can tell if an executable is in use when you update it and figure out which
service is using it.
--
Darren New, San Diego CA, USA (PST)
Forget "focus follows mouse." When do
I get "focus follows gaze"?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Invisible wrote:
> Of course, if I was going to do that, I'd have to sit there and freeze
> the VM at the exact point where the error pops up so I can write down
> precisely what it said.
Does it reboot after the install completes? If not, see if the messages are
out there somewhere, like with the "dmesg" command or whatever it's called?
--
Darren New, San Diego CA, USA (PST)
Forget "focus follows mouse." When do
I get "focus follows gaze"?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> How difficult would it be to detect,
>
> More difficult than the guy writing the software for free felt like
> writing. That's one fundamental problem with FOSS. (Altho that might
> start changing given the number of people now being paid to write FOSS
> is outweighing the number of people not paid to write FOSS.)
...which is interesting, given that SUSE is a Novell product. (Although
we are talking about OpenSUSE here, so maybe that doesn't count?)
> Don't confuse the distro with the OS. Linux installs happily in <32M (at
> least on my set-top box). That a distro takes more isn't a problem
It is if you wanted to use that distro. ;-)
>> Services and applications can be restarted, but the kernel really,
>> really can't.]
>
> This is misleading too. If you're running a web server or a DB server,
> the difference between restarting the services and restarting the kernel
> is minimal. You're still not running while it's happening. And depending
> on what component you've replaced, you very well may not have updated
> everything you think you have. E.g., if you replace the PHP interpreter
> with one that has security bugs fixed, you now have to restart every
> service written in PHP to ensure that fix is in place. Which services
> are they? You can't tell. At least with Windows locking executables that
> are running, you can tell if an executable is in use when you update it
> and figure out which service is using it.
...OK...but isn't this [part of] what package managers are supposed to
manage?
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |