 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 14 Feb 2009 20:03:53 +0000, Orchid XP v8 wrote:
>>> I've got it all straightened out *now*. ;-)
>>>
>>> My problem wasn't actually "getting Linux to work", but rather
>>> "getting Linux to do what I want". But in my experience, Linux package
>>> managers are often very awkward to use. You know - the whole "I want
>>> to install this one package, and no I don't want to also upgrade 3,657
>>> other packages to a different version".
>>
>> openSUSE's package management seems to do pretty well with this. If I
>> want to install Virtualbox OSE, I just run "yast2 -i" (for a graphical
>> way to do this) or "zypper in virtualbox-ose" in a terminal window.
>>
>> The package manager figures out what's needed, resolves all
>> dependencies, and installs the necessary packages.
>
> Yeah. It's great when it works like that. But sometimes it decides that
> it wants to install version X of the thing you asked for, which depends
> on a completely different version of something critical - GCC, the Linux
> kernel, libc, whatever. Obviously, replace that and you have to replace
> half the software on your HD. :-}
Funny, I don't run into that problem - and generally haven't in the
nearly 15 years I've been running Linux.
You *can* run into this if you use nonstandard repos regularly, but I
don't. What's in a repo like the openSUSE repos is tested so that these
types of conflicts don't occur.
Case in point:
--- snip ---
[jhenderson@krikkit ~]$ sudo zypper in virtualbox-ose
Downloading repository 'Packman Repository' metadata [done]
Building repository 'Packman Repository' cache [done]
Reading installed packages...
The following NEW packages are going to be installed:
virtualbox-ose virtualbox-ose-kmp-default libXerces-c-28 libXalan-c-110
Overall download size: 6.2 M. After the operation, additional 26.2 M will
be used.
Continue? [YES/no]:
Downloading package virtualbox-ose-kmp-
default-1.5.6_2.6.25.5_1.1-33.1.x86_64 (1/4), 71.0 K (1.7 M unpacked)
Downloading: virtualbox-ose-kmp-
default-1.5.6_2.6.25.5_1.1-33.1.x86_64.rpm [done]
Installing: virtualbox-ose-kmp-default-1.5.6_2.6.25.5_1.1-33.1 [done]
Downloading package libXerces-c-28-2.8.0-10.1.x86_64 (2/4), 1.0 M (4.5 M
unpacked)
Downloading: libXerces-c-28-2.8.0-10.1.x86_64.rpm [done (200.7 K/s)]
Installing: libXerces-c-28-2.8.0-10.1 [done]
Downloading package libXalan-c-110-1.10-116.1.x86_64 (3/4), 862.0 K (4.4
M unpacked)
Downloading: libXalan-c-110-1.10-116.1.x86_64.rpm [done (91.6 K/s)]
Installing: libXalan-c-110-1.10-116.1 [done]
Downloading package virtualbox-ose-1.5.6-33.2.x86_64 (4/4), 4.2 M (15.6 M
unpacked)
Downloading: virtualbox-ose-1.5.6-33.2.x86_64.rpm [done (12.9 K/s)]
Installing: virtualbox-ose-1.5.6-33.2 [done]
--- snip ---
And just to make the point:
--- snip ---
[jhenderson@krikkit ~]$ rpm -ql virtualbox-ose | grep bin
/usr/bin/VBoxAddIF
/usr/bin/VBoxDeleteIF
/usr/bin/VBoxManage
/usr/bin/VBoxSDL
/usr/bin/VBoxSVC
/usr/bin/VBoxTunctl
/usr/bin/VirtualBox
/usr/bin/vditool
--- snip ---
Nope, these are not source files. These are *binary* files from the
package I installed.
>> While not as common as it used to be, dll hell still (to what I hear,
>> not being a Windows user) happens. But much of the time packages
>> include the version of the DLLs they need and use them rather than the
>> installed system libraries.
>
> This, of course, completely defies the entire purpose of shared
> libraries! :-D
Of course it does. But you were lamenting that "This never happens in
Windows" - this is a big part of the reason why.
>>> Plus getting hold of a human
>>> over IRC seems to be like getting blood out of a stone. I guess
>>> everybody is in a different timezone to me?
>>
>> Try online forums instead - you're already familiar with them. Ubuntu
>> and openSUSE have very vibrant online communities.
>>
>> I never use IRC to ask for help - just never needed that sort of
>> immediacy.
>
> No - this was for help with the open-source project I'm trying to
> contribute to, not for Linux. ;-)
And questions about VirtualBox (for example) are not out of place in an
appropriate Ubuntu or openSUSE community group.
>>> It's sorted now, it just took rather a lot of effort considering the
>>> triviallity of what I actually set out to do. ;-)
>>
>> Which was what, out of curiosity?
>
> I added a section to the user manual. (Which is written in something
> called "docbook", by the way.)
Very cool. Make sure you note that for your CV as well, things like that
can be useful.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Yeah. It's great when it works like that. But sometimes it decides that
>> it wants to install version X of the thing you asked for, which depends
>> on a completely different version of something critical - GCC, the Linux
>> kernel, libc, whatever. Obviously, replace that and you have to replace
>> half the software on your HD. :-}
>
> Funny, I don't run into that problem - and generally haven't in the
> nearly 15 years I've been running Linux.
>
> You *can* run into this if you use nonstandard repos regularly, but I
> don't. What's in a repo like the openSUSE repos is tested so that these
> types of conflicts don't occur.
I'm guessing KNOPPIX is configured to look for something silly. When I
tried to repeat the process with Ubuntu, it was fairly painless. I
remember Gentoo was always a PITA though... and Debian, for that matter.
(Debian was years ago tho.)
>> This, of course, completely defies the entire purpose of shared
>> libraries! :-D
>
> Of course it does. But you were lamenting that "This never happens in
> Windows" - this is a big part of the reason why.
I think maybe like Darren said, people on Windows try to minimise
dependencies. For example, I remember trying to set up an email program
and discovering that you can't install it unless you have sound enabled
in the Linux kernel. (WTF?) Because the package manager thinks foomail
depends on libsound, or something.
>>> I never use IRC to ask for help - just never needed that sort of
>>> immediacy.
>> No - this was for help with the open-source project I'm trying to
>> contribute to, not for Linux. ;-)
>
> And questions about VirtualBox (for example) are not out of place in an
> appropriate Ubuntu or openSUSE community group.
Even if you want to know which one would be the best choice to run
Ubuntu on your Windows box? ;-)
>> I added a section to the user manual. (Which is written in something
>> called "docbook", by the way.)
>
> Very cool. Make sure you note that for your CV as well, things like that
> can be useful.
And you think I embarked on this crazy mission, *why*?? 0;-)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> Of course it does. But you were lamenting that "This never happens in
> Windows" - this is a big part of the reason why.
This really hasn't been a problem in about 8 years. DLL hell was caused by
people replacing working code in the OS directories with broken code. As
soon as you implemented the policy that you can't overwrite microsoft's code
with your own, the DLL hell bits went away.
> Very cool. Make sure you note that for your CV as well, things like that
> can be useful.
Yep. All that stuff is good.
--
Darren New, San Diego CA, USA (PST)
"Ouch ouch ouch!"
"What's wrong? Noodles too hot?"
"No, I have Chopstick Tunnel Syndrome."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
So OK, so it's saturday night... and I'm recompiling my compiler. o_O
Yah, that's right. First you install a binary version of the compiler.
Then you use that to compile a minimal version of the compiler from
source. Then you use *that* to compile a full version from source.
Not forgetting that since the compiler is written in the same
programming language, gotta compile all the standard libraries twice
too. Oh, and then on the final pass, the libraries get compiled into
several versions - "normal", "debug", "profiling", etc. And the user
manual needs to be converted from DocBook to HTML - but you don't need a
compiler for that, fortunately!
I should probably get out more...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 14 Feb 2009 20:26:20 +0000, Orchid XP v8 wrote:
>>> Yeah. It's great when it works like that. But sometimes it decides
>>> that it wants to install version X of the thing you asked for, which
>>> depends on a completely different version of something critical - GCC,
>>> the Linux kernel, libc, whatever. Obviously, replace that and you have
>>> to replace half the software on your HD. :-}
>>
>> Funny, I don't run into that problem - and generally haven't in the
>> nearly 15 years I've been running Linux.
>>
>> You *can* run into this if you use nonstandard repos regularly, but I
>> don't. What's in a repo like the openSUSE repos is tested so that
>> these types of conflicts don't occur.
>
> I'm guessing KNOPPIX is configured to look for something silly. When I
> tried to repeat the process with Ubuntu, it was fairly painless. I
> remember Gentoo was always a PITA though... and Debian, for that matter.
> (Debian was years ago tho.)
Well, KNOPPIX is primarily designed to run from the disc as I recall, so
it makes sense that package management wouldn't be as robust as on full-
on distributions.
>>> This, of course, completely defies the entire purpose of shared
>>> libraries! :-D
>>
>> Of course it does. But you were lamenting that "This never happens in
>> Windows" - this is a big part of the reason why.
>
> I think maybe like Darren said, people on Windows try to minimise
> dependencies. For example, I remember trying to set up an email program
> and discovering that you can't install it unless you have sound enabled
> in the Linux kernel. (WTF?) Because the package manager thinks foomail
> depends on libsound, or something.
Well, here again, this isn't something that I have recently run into.
But you can generally override the dependencies if you want; I converted
a Debian package to run on openSUSE (a video converter called HandBrake),
and the library dependencies weren't met because the library is called
something else on Debian (and yes, I do find that kinda frustrating). So
I installed with --nodeps and linked to the library name on openSUSE.
Works perfectly.
But that was the exception in my experience.
>>>> I never use IRC to ask for help - just never needed that sort of
>>>> immediacy.
>>> No - this was for help with the open-source project I'm trying to
>>> contribute to, not for Linux. ;-)
>>
>> And questions about VirtualBox (for example) are not out of place in an
>> appropriate Ubuntu or openSUSE community group.
>
> Even if you want to know which one would be the best choice to run
> Ubuntu on your Windows box? ;-)
Sure, why not? You think that people in the Ubuntu forums only ever run
their distro on real hardware?
>>> I added a section to the user manual. (Which is written in something
>>> called "docbook", by the way.)
>>
>> Very cool. Make sure you note that for your CV as well, things like
>> that can be useful.
>
> And you think I embarked on this crazy mission, *why*?? 0;-)
Good lad. ;-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 14 Feb 2009 12:29:42 -0800, Darren New wrote:
> Jim Henderson wrote:
>> Of course it does. But you were lamenting that "This never happens in
>> Windows" - this is a big part of the reason why.
>
> This really hasn't been a problem in about 8 years. DLL hell was caused
> by people replacing working code in the OS directories with broken code.
> As soon as you implemented the policy that you can't overwrite
> microsoft's code with your own, the DLL hell bits went away.
I might go as far as 6 years ago, but I remember the folks doing package
management for desktop distribution in the company I worked for at the
time having to jump through all sorts of hoops to get some programs to
work together because of differences in DLL versions. We had something
like 15,000 desktops total and had to test all applications against all
others generally before rolling them out. We had a team of 4-6 people
who worked on the packaging.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 14 Feb 2009 21:29:40 +0000, Orchid XP v8 wrote:
> Yah, that's right. First you install a binary version of the compiler.
> Then you use that to compile a minimal version of the compiler from
> source. Then you use *that* to compile a full version from source.
That used to be common with GCC - not sure if that's the one you're
using, but I remember the first time I saw it built was on a SunOS
platform, used the Sun CC compiler to build the first time and then it
built itself in order to fully optimise itself.
On hardware of the time, it generally took about 12 hours IIRC.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> work together because of differences in DLL versions.
I suppose it's not completely solved anywhere, no. But it's a lot better
than it was. At least DLL hell only affects third-party DLLs now, and
installing software that *doesn't* share DLLs won't break your code. :-)
It used to be a lot worse, tho, especially with things like third-party tcp
stacks (i.e., winsock.dll), where every browser came with a different
implementation of TCP and such. Or the MS C runtimes, or the "New" 3D
button graphics libraries, etc. People would do things like try to replace
the GUI libraries with their own in order to put their own "theme" on
things, thereby breaking everyone else who actually based their code on
released OS files. :-)
--
Darren New, San Diego CA, USA (PST)
"Ouch ouch ouch!"
"What's wrong? Noodles too hot?"
"No, I have Chopstick Tunnel Syndrome."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> That used to be common with GCC
I remember seeing the bootstrap code for compiling Hermes, which had its own
assembly language that looked a lot like SQL for example. :-) It had
comments in there like "Only Greg, the God of Awesome, is allowed to touch
this, because the rest of you keep screwing it up."
--
Darren New, San Diego CA, USA (PST)
"Ouch ouch ouch!"
"What's wrong? Noodles too hot?"
"No, I have Chopstick Tunnel Syndrome."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 14 Feb 2009 13:46:03 -0800, Darren New wrote:
> Jim Henderson wrote:
>> work together because of differences in DLL versions.
>
> I suppose it's not completely solved anywhere, no. But it's a lot better
> than it was. At least DLL hell only affects third-party DLLs now, and
> installing software that *doesn't* share DLLs won't break your code. :-)
I'd go with that....
> It used to be a lot worse, tho, especially with things like third-party
> tcp stacks (i.e., winsock.dll), where every browser came with a
> different implementation of TCP and such. Or the MS C runtimes, or the
> "New" 3D button graphics libraries, etc. People would do things like
> try to replace the GUI libraries with their own in order to put their
> own "theme" on things, thereby breaking everyone else who actually based
> their code on released OS files. :-)
Yeah, I can remember back in the Win9x days there being 3rd party TCPIP
stacks that you could create all sorts of havoc with.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
