 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Invisible <voi### [at] devnull> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Invisible <voi### [at] devnull> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> ...which is interesting, given that SUSE is a Novell product. (Although
> we are talking about OpenSUSE here, so maybe that doesn't count?)
I wasn't talking specifically about one package or another. Just in general.
> ...OK...but isn't this [part of] what package managers are supposed to
> manage?
Tell me how a Linux package manager is going to tell you whether anyone is
currently running a program that needs some DLL it's going to replace.
--
Darren New, San Diego CA, USA (PST)
Forget "focus follows mouse." When do
I get "focus follows gaze"?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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?
It says it's going to "reboot", but there's no BIOS screen. I don't know
if it just stops one kernel and loads the other or what...
Trying to pause the VM at the right instant would probably be a lot less
work than trying to figure out Linux.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 26 Jan 2010 11:17:47 +0000, Invisible wrote:
> I used to quite like OpenSUSE. However, the other day I installed it
> about 13 seperate times. Let me tell you why.
If you were to ask some questions over in forums.opensuse.org, I'm sure
someone would be happy to help you out with the issues.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 26 Jan 2010 08:18:07 -0500, Warp wrote:
> Linux doesn't support switching kernels on-the-fly. Not many OSes do.
The stock kernel doesn't, but there is a company that has developed a way
to patch the live kernel and have the patch take effect. I forget who it
is, but I've heard about it and from people who've used it.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 27 Jan 2010 18:44:18 +0100, Jim Henderson <nos### [at] nospamcom>
wrote:
> On Tue, 26 Jan 2010 08:18:07 -0500, Warp wrote:
>
>> Linux doesn't support switching kernels on-the-fly. Not many OSes do.
>
> The stock kernel doesn't, but there is a company that has developed a way
> to patch the live kernel and have the patch take effect. I forget who it
> is, but I've heard about it and from people who've used it.
http://www.ksplice.com
--
FE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am Tue, 26 Jan 2010 16:25:59 -0800 schrieb Darren New:
> Orchid XP v8 wrote:
>> ...which is interesting, given that SUSE is a Novell product. (Although
>> we are talking about OpenSUSE here, so maybe that doesn't count?)
>
> I wasn't talking specifically about one package or another. Just in
> general.
>
>> ...OK...but isn't this [part of] what package managers are supposed to
>> manage?
>
> Tell me how a Linux package manager is going to tell you whether anyone
> is currently running a program that needs some DLL it's going to
> replace.
If it is done correctly, it knows which programs depend on the "DLL" and
is going to update this programs as well, then - if they are running - it
will ask the user to restart this programs. At least Ubuntu asks me about
restarting the program. (Also, if I run an executable it seems "locked",
at least it refuses to overwrite it - which sounds to me the same as what
you described, what windows is doing, or do you mean something else?)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 27 Jan 2010 19:45:32 +0100, Fredrik Eriksson wrote:
>> The stock kernel doesn't, but there is a company that has developed a
>> way to patch the live kernel and have the patch take effect. I forget
>> who it is, but I've heard about it and from people who've used it.
>
> http://www.ksplice.com
That's the one I was thinking of, yes. :-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Florian Pesth wrote:
> If it is done correctly, it knows which programs depend on the "DLL"
No, it knows which *packages* depend on the DLL.
There's no good way under Linux (without walking thru /proc and trying to
parse it, and hoping it doesn't change while you do so) of telling what DLLs
a given program is using that isn't in a package. There's also no good way
of telling what programs are running right now. There's also no good way of
figuring out if a currently-running program is compatible with the new DLL
you just downloaded, even if that running program hasn't loaded that DLL.
(For example, you have your media player running, and you update the media
player executable and all the codecs. But now you go back to the running
media player and play a different file, which loads the new codec DLL that
is now incompatible with the running executable.)
UNIX has always been a "95% is good enough" OS. Linux is doing slightly
better, but still isn't 100% there.
> (Also, if I run an executable it seems "locked",
You can't write to a program that's executing, in UNIX. Never could.
What you *can* do is delete the executable while it's running (well,
technically, "unlink" it), and create a new file with the same name.
In Windows, to delete a file, you have to have write permission, and since
you don't get write permission to an executing file in Windows (just like in
UNIX), you can't delete the file.
In UNIX, you don't need any permissions on a file to unlink it from the
directory its name is in.
--
Darren New, San Diego CA, USA (PST)
Forget "focus follows mouse." When do
I get "focus follows gaze"?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am Wed, 27 Jan 2010 14:11:40 -0800 schrieb Darren New:
> Florian Pesth wrote:
>> If it is done correctly, it knows which programs depend on the "DLL"
>
> No, it knows which *packages* depend on the DLL.
>
> There's no good way under Linux (without walking thru /proc and trying
> to parse it, and hoping it doesn't change while you do so) of telling
> what DLLs
> a given program is using that isn't in a package.
Right, if you install programs not in the package management, the package
management doesn't work on this programs. But this is to be expected,
isn't it?
(BTW, how do you ensure "atomic" process table lookups on any
multitasking OS? It is not, that you can prevent the starting of new
processes just after your check, can you?)
There's also no good
> way
> of telling what programs are running right now.
Just out of curiosity: Is there any way to tell of a process in windows,
which executable file it stems from? What happens, if you unmount the
volume the executable file is on or if the process you are looking at is
actually a child process from the original one?
> There's also no good
> way of figuring out if a currently-running program is compatible with
> the new DLL you just downloaded, even if that running program hasn't
> loaded that DLL.
Again, how do you expect to solve this problem without some form of
either package management or a different centralized software
distribution system (for example like the App store for the iPhone)? I
can always compile a DLL with a same name which is incompatible to what
some program expects. That can only be solved by package management.
>
> (For example, you have your media player running, and you update the
> media player executable and all the codecs. But now you go back to the
> running media player and play a different file, which loads the new
> codec DLL that is now incompatible with the running executable.)
If the package management works, this is what happens:
You update the *package* of the media player. When you do this the
package manager notices, that you have an older version of that package
installed and checks if you have an instance of the program running (It
doesn't really matter, if this check is done in a nonstandard way,
because the package manager knows *exactly*, what version is installed
and how to check it.). It pops now a window asking you to restart the
player.
Of course if you don't use the package management you might break the
system, but thats not different than tinkering with windows on a low
level.
>
> UNIX has always been a "95% is good enough" OS. Linux is doing slightly
> better, but still isn't 100% there.
Sure, it is still some way to go (I'm doing some administration on some
linux machine on my job, but my primary job is using them for physics
simulations - so its pretty annoying if the stuff doesn't work. And yeah,
if it works for "practical purposes" its fine for me, even if it is
technically broken.)
>
>> (Also, if I run an executable it seems "locked",
>
> You can't write to a program that's executing, in UNIX. Never could.
>
> What you *can* do is delete the executable while it's running (well,
> technically, "unlink" it), and create a new file with the same name.
>
> In Windows, to delete a file, you have to have write permission, and
> since you don't get write permission to an executing file in Windows
> (just like in UNIX), you can't delete the file.
>
> In UNIX, you don't need any permissions on a file to unlink it from the
> directory its name is in.
Thanks, didn't know that!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Florian Pesth wrote:
> Right, if you install programs not in the package management, the package
> management doesn't work on this programs. But this is to be expected,
> isn't it?
Yep. But notice how this differs from Windows. If it can replace a DLL, it
means nobody is using it right now, whether that program is in the package
management system of Windows or not.
> (BTW, how do you ensure "atomic" process table lookups on any
> multitasking OS?
Well, you could do something like (for instance) trying to open the
executable for writing. If it fails, someone is running it. If it succeeds,
then nobody at this point can "exec" it, because they'll get back that the
file is busy from the exec call.
At least, that's how it works on serious operating systems, like mainframes.
Everything you would commonly want to do is atomic in one way or another.
> Just out of curiosity: Is there any way to tell of a process in windows,
> which executable file it stems from?
Sure. The task manager does it no problem, so I can't imagine it's hard.
> What happens, if you unmount the
> volume the executable file is on
Dunno, offhand. I suspect either it doesn't let you unmount it or the
process gets killed before the unmount completes.
> or if the process you are looking at is
> actually a child process from the original one?
Which would the "original" one be?
>> There's also no good
>> way of figuring out if a currently-running program is compatible with
>> the new DLL you just downloaded, even if that running program hasn't
>> loaded that DLL.
>
> Again, how do you expect to solve this problem
This one is definitely more difficult, yes. In Windows, this is part of what
the COM system does, or you use NTFS atomic transactions. So either you say
"replace all these files including the executable" and the executable fails
so none get replaced, or you put the new COM software out there and
atomically update the registry to point to the new COM server.
> can always compile a DLL with a same name which is incompatible to what
> some program expects. That can only be solved by package management.
Sure. I'm just saying that package management systems fall down at some
point, more or less complexly. You *can* ensure this doesn't happen under
some systems. UNIX isn't one of them, because the semantics aren't there in
the atomic parts of the system.
There's a reason it's called the "registry".
> If the package management works, this is what happens:
> You update the *package* of the media player. When you do this the
> package manager notices, that you have an older version of that package
> installed and checks if you have an instance of the program running (It
> doesn't really matter, if this check is done in a nonstandard way,
> because the package manager knows *exactly*, what version is installed
> and how to check it.). It pops now a window asking you to restart the
> player.
How does it know how to check if some random user is using an arbitrary
program at the moment? Or if that program is running in a way that can't be
interrupted with a "window"? What if I started some long-running data
munching job in the background and logged out. Who do you ask if you can
replace its DLLs? Or if it's not in a package but the DLLs it's using are?
> if it works for "practical purposes" its fine for me, even if it is
> technically broken.)
Yeah, I grew up on mainframes where the folks writing the OS actually paid
attention to all the corner cases, so it bugs me when there's no guaranteed
way to see if something is already running, etc.
It's only since /proc came along that you could even tell if a service was
already running and not restart it if it was.
> Thanks, didn't know that!
Yeah, Windows doesn't have a problem deleting an open file in general. It
just has a problem deleting an open file that you specifically said "don't
let others delete this while it's open." It just happens that the OS opens
executable code files that way, so it can page out of the files directly
without copying them to swap space.
--
Darren New, San Diego CA, USA (PST)
Forget "focus follows mouse." When do
I get "focus follows gaze"?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Invisible <voi### [at] devnull> 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.
Yes it does, search for "kexec".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> There's no good way under Linux (without walking thru /proc and trying to
> parse it, and hoping it doesn't change while you do so) of telling what
> DLLs a given program is using that isn't in a package. There's also no
> good way of telling what programs are running right now.
fuser and lsof can tell you what programs currently have a certain file
open. Probably it's race-condition-prone. Probably theu work by walking
through /proc and parsing it.
> There's also no good way
> of figuring out if a currently-running program is compatible with the new
> DLL you just downloaded, even if that running program hasn't loaded that
> DLL.
If a shared library is ABI-incompatible, it will have a different soname,
which means it will have a different *filename* too. Programs linked to the
old version of the library won't be *able* to load the new version, and
viceversa.
> (For example, you have your media player running, and you update the media
> player executable and all the codecs. But now you go back to the running
> media player and play a different file, which loads the new codec DLL that
> is now incompatible with the running executable.)
For dynamically-loadable libraries like that, it may need a custom solution,
such as a function (with stable ABI by itself!) that can be called to ask
the codec's ABI version, so the media player can tell if it's compatible.
Or don't break the compatibility to begin with ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> fuser and lsof can tell you what programs currently have a certain file
> open.
There is that, yes.
> Probably it's race-condition-prone. Probably theu work by walking
> through /proc and parsing it.
""" Since lsof reads kernel memory in its search for open files, rapid
changes in kernel memory may produce unpredictable results."""
I.e., it works like "ps" used to before /proc. And yes, it looks like it
would be race-condition prone. But probably good enough, really.
Lacking a transactional capability is also problematic. If you get half way
through the upgrade of something and your program or even system crashes,
you could be screwed, especially if what got corrupted was important to
getting the system running again. I'm not sure if Linux has transactional
file systems in common use. But again, that's off topic to the original
"Windows locks executables" rant and more onto "mainframes actually worried
about this crap." Or more precisely, people actually worry about this crap
when a crash costs actual real large amounts of money per second of downtime.
> If a shared library is ABI-incompatible, it will have a different soname,
> which means it will have a different *filename* too. Programs linked to the
> old version of the library won't be *able* to load the new version, and
> viceversa.
That's a point, yes. Assuming you manage to avoid DLL Hell.
> Or don't break the compatibility to begin with ;)
Such is rarely done on purpose, yes.
--
Darren New, San Diego CA, USA (PST)
Forget "focus follows mouse." When do
I get "focus follows gaze"?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez <nic### [at] gmailcom> wrote:
> Warp wrote:
> > Invisible <voi### [at] devnull> 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.
> Yes it does, search for "kexec".
As far as I understand, kexec does not allow switching kernels on the fly.
It's simply a mechanism for rebooting (an already running system) faster by
bypassing most of the tasks done during a regular boot (ie. detecting and
configuring devices). I don't think it allows for programs to keep running
through the reboot. (In other words, there's still a downtime of the system
involved. It's just significantly shorter than with a normal reboot.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>> Yes it does, search for "kexec".
>
> As far as I understand, kexec does not allow switching kernels on the fly.
> It's simply a mechanism for rebooting (an already running system) faster by
> bypassing most of the tasks done during a regular boot (ie. detecting and
> configuring devices). I don't think it allows for programs to keep running
> through the reboot. (In other words, there's still a downtime of the system
> involved. It's just significantly shorter than with a normal reboot.)
In fact, I think this [or something like it] is what OpenSUSE does when
it's finished installing everything. It says it's going to reboot, but
it doesn't actually reach the BIOS screen.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
