>Well, then MySQL is just a server (aka listener) >to a database toolkit. It doesn't make it as a >database server iether.
Any MySQL build includes: a listener, a query engine, and a backend. Just because you can change the backend doesn't make it any less of a database server.
>One comment in the Life After Redhat article stuck >out. He loves FreeBSD and his systems are >"upgraded once a week (all software)". Is this >normal pratice? I still have SuSE 6.3 systems >running.
"Normal practice" varies depending on who you're talking to.:)
On the networks I administrate, I have a strict policy of "no unjustified upgrades", which usually translates to applying only security patches and relevent bug fixes. It might include new versions of software if, and only if, we're rolling out an enhancement to our services that necessitates it.
Part of the reason for being so restrictive is because we do QA and testing after every upgrade, so all upgrades have an associated cost in admin time. It may seem overly paranoid, but we've caught a lot of subtle issues that would have otherwise effected service to our customers.
>If all you want or need is a glorified Berkely DB, >that's fine -- but stay away from anything >mission-critical.
This statement doesn't really make any sense, since BerkelyDB is primarily a database toolkit, not a database server. It doesn't even implement SQL or any other quasi-relational language, just programming APIs.
It also implies that BerkleyDB is somehow feature limited, which really isn't the case. It supports transactions with full rollback capability, replication and transparent failover, load balancing, write ahead logging and checkpointing, hot backups, etc, etc.
It might not make sense for a general purpose database, but if you have predictable access patterns, it can seriously rock, particularly if you want to embed database features into an application.
Moby had more than a few words about Eminem at the Grammy awards. Don't feel like getting into an argument about whether he's a homophobe or mysoginist, but the allegations of racism are amusing given his contemporaries.
"He's very good at what he does and he's very clever, but he's also a misogynist, a homophobe, a racist and an anti-Semite... I don't see how I can lend any sort of support to an artist like that."
"OK, well maybe I'm making an assumption. Maybe I'm painting with a broad brush. But do you know that he's not an anti-Semite? I'm pretty sure, I've read interviews where he says something anti-Semitic. In any case, even if he's not an anti-Semite, he's still a racist, a homophobe and a misogynist."
"I was talking to somebody earlier about the notion of Eminem being in the continuum of Elvis Presley, the Sex Pistols, Public Enemy, and Kurt Cobain. But the difference is that they were all rebellious in the sense that they were extending boundaries -- creating culture that broadened people's perspectives. The problem with Eminem is he's creating culture that appeals to the lowest common denominator."
Matt
Re:Gentoo is a giant step, too long for mere morta
on
Is RPM Doomed?
·
· Score: 2
Actually, the X forwarding stuff isn't a compile time option. It won't work unless you have X installed, of course, but it doesn't break it if you don't.
The packages that have options that would cause dependencies (e.g. emacs with X11 support) are in fact often split into different pacakges - emacs-nox and emacs-X11, vim-common/enhanced and vim-X11. Other ones take advantage of software that has modules, such as apache and perl. And a large number of other packages are compiled with optional features enabled, but not turned on in the config files.
Big dependencies (e.g. X, Python, Perl) *are* seperated out into their own packages, and in most cases other features are turned on by default. And once you start looking at desktop level software, configuration is usually done within the application, not compile time. But even when that's not the case, it is often provided with plugins its easy to package on their own (look at GStreamer, the multimedia framework - each codec that has an external dependancy is split out into a seperate RPM so you can install only those features that you actually need).
My main point is that most people *don't* do customization on their software. Remember, the mantra of source code advocates is "but compiling is easy, it's just./configure && make && make install!".
I can see the appeal of something that automatically configures itself based on what you have installed, even if I see it being of limited utility. And I can see some issues with it, such as the gentleman who pointed out that in Gentoo, if you compile with a library installed, then remove that library, it will silently break the application.
As for difficulty in custom compiling RPMS, it's really not nearly as difficult as people make it out to be. On a lot of packages, if you do a rpm --rebuild on a SRPM, it runs through a straight configure that detects what libraries are installed, and the find-requires script will write your new RPM with all the proper dependencies.
And if you need to change an implicitely specified option, you can install the source rpm, change the "./configure" line in the spec file, and rpm -ba it.
But most of the time this really doesn't buy you much. I run about 60 Red Hat machines and the only custom RPMs we need is software that was written or modified in house, and the kernel, since there was a particular issue that we needed to patch away (a two line change to the spec file).
>This is surely due to the various distributions
>not conforming to the LSB and FHS, rather than the
>shortcomings of the package management system?
>Debian is far more standards-complient than
>RedHat, and Slackware is even better.
Sorry, but Red Hat's lack of complaince (or lack of willingness to comply) with the LSB is a myth.
These aren't the official results, but preliminary test results at
freestandards.org show Red Hat as passing more tests than Debian, SuSE, and Caldera.
Among some of the issues that Debian were that their init scripts didn't provide a status command, and that there was no distinction in runlevels 2-5. I haven't kept up with development too closely, but my Debian installation, which has been apt-get upgraded fairly recently still has these issues.
As for Slack, last word from Patrick Volkerding that I know of is that he's taking a "wait and see" approach; i.e. he's not even bothering to strive for LSB complaince until he's convinced that compatibility is improved between compliant distributions, although to his benefit he said "I'm sure this is a step in the right direction."
I haven't used 8.1 at all, but Slackware probably has the most work cut out for it if they decide to try to move towards LSB compliance - their init levels are non-standard, their init scripts are completely non-standard (kind of a weird hybrid BSD/SysV approach), they fail a good potion of the FHS tests, etc, etc.
In other words, nit picking aside, Red Hat and Deibain are pretty much on par as far as comformance go, and Slackware is way off.
Matt
Re:My Linux Expiriances...
on
Is RPM Doomed?
·
· Score: 2
>Now it's true that Potato (aka Stable) is out of >date. It's stable as hell, but I don't think any >desktop user should use it (servers are another >story, as is often the case). "Testing" has been >just as stable for me as full releases of >Mandrake and others, that is no crashes. I've >never used unstable, but hey, I've got a extra >box lying around here somewhere.
Just to reiterate... SERVERS ARE ANOTHER STORY... I've seen a number of people saying that they keep the servers they admin up to date by putting an apt-get update in cron, and also that they use testing because it's "stable as other distributions".
But I've had serious issues on a home box that I upgraded with the testing branch in a futile quest for more up to date software; e.g.
sendmail was 'upgraded' to store its mail
spool in a different location, without any
clear notification, without moving the mailboxes
or putting in a symlink, without changing any
of the other mail programs to look there...
apache was 'upgraded' to a version that was
compiled with large file support, but didn't
have a dependcy on a kernel that could support
this so it would randomly crash...
for some ungodly reason it decided to install
z-mailer and wouldn't let me uninstall it even
though no packages depended directly on it or
on an mta at all (iirc it required deleting
a symlink somewhere on the system or something)
several of the packages are compiled such that
they are trying to use unimplemented syscalls
(likely compiled against a different variant
of the sun4 architecture than I have)
And those are only the issues that come to mind. I'm still pondering whether I want to give OpenBSD or NetBSD another try, but last I checked their NIS implementation was piss poor.
Matt
Re:Gentoo is a giant step, too long for mere morta
on
Is RPM Doomed?
·
· Score: 2
>Have you tried doing a minimal install, with ssh, >but without X? > >Actually - I'm kinda bluffing that it won't work >here, it didn't work on SuSE so I'm assuming it >won't work on RH either.
Works just fine. Just because two distributions are rpm based doesn't mean they make the same mistakes.
Actually, the only thing that Red Hat makes you install is the "base" package list. Comes to maybe 200MB and contains, IMHO, very little crack rock. About the only things I might be inclined to strip out are slocate (not exactly a good thing on high volume servers with millions of files), gpm and mouseconfig (sixty servers, no mice).
Don't take this as a personal affront, but it constantly amazes me how ungrounded in reality many people's complaints against Red Hat are; e.g. they turn every service on by default, they don't test their software before shipping it, their minimum install is bloated (feel free to take offense at that, if you must), they're not striving for LSB compliance, etc, etc.
There may be some cases where they were guilty in the past, but they've done a more than adequate job of responding to issues when they crop up and are, IMHO, one of the better distributions out there.
Matt
Re:Luke, use the source...
on
Is RPM Doomed?
·
· Score: 3, Informative
It's really not that hard to figure out:
rpm --rebuild whatever.srpm
Your shiny new binary RPM(s) will be in whatever the system path is for RPM (on Red Hat it's/usr/src/redhat/RPMS).
And the binary RPMs will end up in the same place. Plus with that method is you can edit the spec file for customization.
Most people who gripe about RPMs being too hard probably have never looked at the spec files before - all they are is some meta information and a shell script that builds the program. Building from scratch may be hairy for a new user, but customizing an existing package is REALLY easy; usually it's just a matter of looking for a line starting with "./configure" and adding the options you want after that.
Why go through the trouble when you could do it from source? It is much much easier for replicated installs, you don't have to worry about stray files lying all over the place, its easy to tag files as being configuration so they don't get overwritten, etc, etc.
>Oh, I don't know. Maybe the fact that Amazon >doesn't actually create the products they >facilitate the sale of, used or new.
Car dealerships manufacture their own cars now?
>Maybe the fact that used car sales are an >essential component of marketing new cars (the >trade-in market). So much so that many >manufacturers have their own "certified" used car >programs.
And it's far from unlikely that people who are selling books on Amazon and E-bay won't use some of the profit to buy more books. I myself do this.
So the analogy isn't perfect. None are. But the point is that the transaction happens with no benefit to the original seller because they already sold it.
>Everyone who cares about network transparency and >X and legacy unix apps, the first thing they say. > >You guys use linux because its a job, i bet you >use windows at home, I use linux as my primary >desktop, at HOME.
As other pe ople have pointed out, you lose.
I've been running Linux at home since 1995. By 1996 I wiped out my Windows partition.
Now I've got three machines running Linux, one running OpenBSD, and have machines running HP/UX and Solaris on the way.
Guess what - only one of my machines has a monitor on it.
>Some day is now. Xenix became SCO UnixWare became >Open UNIX 8 [caldera.com].
Not quite.. As I pointed out in an earlier post Xenix became SCO UNIX which became SCO Openserver. It was originally based on V7, and later SVR2 and SVR3.2, with features from SVR4 either backported or reimplemented when it became Openserver.
Unixware was an SVR4.2 implementation SCO aquired from then owner Novell. It was sold pretty much unchanged as Unixware 2.x for several years.
In 1998 they released Unixware 7, which was touted as being the first SVR5 implementation. Since SCO now controlled the Unix codebase, they could bump the version number:). This release did include some features designed to ease transition from Openserver 5, but it was an evolution of the SVR4.2 codebase of Unixware, NOT the SVR3.2 codebase of Xenix.
The closest thing to a remaining relative would be Openserver 5.0.6, which is still marketed by Caldera.
Maybe you're just unlucky:) I worked support at a large company, mostly on Unix systems. So I've walked people through SCSI configurations on HP/9000s, Sparcs, Vaxen, Alphas, PeeCees, Macs running HP/UX, SunOS, Solaris, Digital Unix, OSF/1, Openserver, Unixware, SCO 3.2v4.2, Xenix, Linux, FreeBSD, Windows, MacOS... I think the only really weird problem I saw beyond driver issues was one machine which would only work unterminated.
I any case, its not perfect, but considering the SCSI standard deals with a mish-mosh of signaling, ranging from 5MHz to 80MHz, single ended or differential, 8 or 16 bit, single or double pumped, synchronous or asynchronous operation... Not to mention various extentions to the protocal including packetized scsi, domain validation, etc, etc...
Honestly, I'm amazed that they've managed to push the speed up well over 100x what the original 8-bit narrow async standard pushed, and you can still slap on an adapter and have a damn good chance of it working.
Matt
Re:FireWire is already on the ball.
on
Serial ATA Coming
·
· Score: 2
>Other than the touted 600Mb data rate versus 400Mb >for FireWire [apple.com],
It's 600MB, not 600Mb, and that's in a future revision. The initial devices will be 150MB vs 400Mb on firewire, or about three times faster than firewire.
>to compete with the firewire (and upcoming >gigawire) "standard" and the usb 1.x and 2.x >"standards". oh and we have ata/133/100/66 >"standards". scsi >1/2/3/4/5/ultra/wide/thin/mega-super-fun >"standards" too. > >how come none of my "standard" devices talk to >each other very well?
How do SCSI devices not talk to one another well? I've run SCSI-1 devices on Ultra2 controllers and vice versa without a single glich. Likewise, I've run ATA/33 devices on ATA/100 controllers and vice versa without a single glich.
I have little experience with either USB or Firewire, but I've never heard of problems with backwords compatibility on either of them.
>Eventually Linux might have this feature... yet >more evidence that *bsd is years ahead of linux
No, its evidence that you don't know what you're talking about. Linux has supported immutable and append-only flags since the 1.1 series of kernels, way back around 1994.
>Okay, let me be sure I understand this - Miguel >and his gnomies wanna base GNOME on MONO which \ >is an open source implementation of.NET - which >was developed to compete with Sun's Java - and >Sun's throwing developers at this?
A few things:
The only developer who has said they are interested in making Gnome "based on" Mono is Miguel. Your inclusing of "and his gnomies" seems to imply that this is a widespread intention; it is not.
The term "based on" is misleading. As Miguel himself said:
Rewriting GNOME in C# with the CLR would be a
very bad idea, if not the worst possible idea
ever.
And furthermore Mono is being based on Gnome technologies, not the other way around:
Libart will be used to implement the
Drawing.2D API; Gtk+ and the GNOME libraries
will be used to implement the WinForms API and
of course Glib and libxml will be used in
various places
If anything, it would be more accurate to say that Mono is being offered as an alternate API for accessing the Gnome libraries, and that Miguel has belief that this API offers signifigant enough advantages that future code may be based on Mono, or embed the Mono runtime.
The next thing is that this has nothing to do with Gnome 2.0, which is the project that they will be working on. Miguel stated he would like to see Gnome 3.0 have Mono ties, but he has also stated that his guess is that Gnome 4.0 would be when developers start seeing the benefits of it.
And of course, the more important point - Miguel does not have maintainer control over ANY package in Gnome. He has long since given maintainership on every project he worked on to someone else.
What this means is that the only thing that will move Gnome to dependency on Mono is if it is reached as a consensus among the Gnome developers.
There is a black and white issue here. Distributing copies of a copyrighted work without the permission of the "author" is illegal. However, in my opinion, it is far from being in the publisher's best interest to take action against the distribution of abandonware titles.
The questions they should be asking themselves are:
1) Does this harm us?
2) Can we capitalize on this?
The first question pretty much comes down to two key issues - is there loss of revenue, and does it dilute intellectual property.
Unless there are ongoing efforts to sell a particular title, it is not generating a revenue stream. This is pretty straight forward.
There may be a question as to whether it could be used to generate a future revenue stream; e.g. via the release of "classic" packs. This, however, is not feasible in a games current form unless it runs on a currently available platform.
So, in terms of revenue, the publisher is out of luck unless it runs on Windows or Macintosh. They may do an port of older games, but that depends on a value add in order to make it a sellable asset.
The second issue - protection of intellectual property - is pretty much a red herring. These are not trademarks; no matter how many times someone illegally copies them, it will not prevent them from successfully enforcing copyright on them in the future.
So onto the second question - can this be capitalized on? The answer here is a resounding YES.
The biggest benefit of abandonware, illegal or not, is that it helps maintain a franchise. If there is any question of the value of having a well known, wide spread franchise, one only need look at Ninetendo.
There is also a lot of good will to be culled from releasing old games (in their current form, not applicable to future releases) under a free beer license.
What my suggestion to publishers would be is to release these games under a license allowing free play, but not free redistribution, and then license redistributions rights to abandonware sites, not for money, but for advertising space.
When applicable this would make an ideal launching pad for advertising updates of old classics, or new games in a series, as it targets the people who loved the originals enough to go searching for them.
Of course, this is only my opinion, and doesn't count for jack in the real world:)
Again with the epithets. This hardly gives confidence in the strentgh of your arguments.
>Suppose that I want to migrate one x86 linux >server (for example Mandrake 7.2 based, which >runs Oracle 8i well) to a s/390 VM. Will it be >easy because there is MDK for the s/390? I doubt >it.
Well, before I address that, I quote your original post:
the mind boggles... do you really believe that
Mandrake or RedHat will install on the s/390?
The question has nothing to do with whether it would make anything easier, just whether it will install. Which it will.
As for whether it would be make the port any easier? On Mandrake, no, as it has no S/390 port.
However, Oracle, like most of the ISVs that have released software for Linux/390, support SuSE exclusively, as they had the first comprehensive commercially supported distribution for the S/390.
Even if you're not using a commercially supported product such as Oracle, there is a distinct advantage to being able to utilize the same platform on the S/390 as your current Intel machines. The most obvious one is retraining, integration with current systems (e.g. patch management), and ease of porting (yes, some software needs to be "ported" between distributions, due to different versions of compilers, libraries, and directory layout).
>SUSE's say it includes XFree (I wonder how X can >run on an s/390... but I may be talking my ass >here since the last MF I worked on was an old >3090)
The same way it runs on headless servers - remotely, either on an application by application basis, or through XDM.
>Turbolinux asked me to register to see more >stuff,so I ditched it. what kind of freak use >that anyway?
Not for me to say, but they have a signifigant customer base.
>Debian is beta, but it is promising. Debian >dudes are serious, but their attitude kinda >kills them in the corporate world. no >proprietary software? haha, dream on.
Personally, I've not been happy with the Debian boxes I've had to administer. However, there are a signifigant number of companies running it.
>So, don't be so touchy, you sissy. Any serious >production environment of linux on s/390 will >use an IBM's blessed distro, not that crap.
I actually had a S/390 onsite for evaluation last year. Do you know what distribution IBM recommended? SuSE.
Do you know why? IBM doesn't have a Linux distribution. They have a set of kernel patches available to support the S/390, and links to Red Hat, SuSE and Turbolinux.
>The alarming thing is that they are producing >their OWN version of Linux, not using Redhat or >another company. And also IBM I understand is >doing this too.
IBM has actually done a commendable job of keeping their support for Linux as vendor agnostic as possible, while still working with Red Hat, SuSE and TurboLinux for more comprehensive services.
Though, not being an IBM executive, I cannot rule out the possibility of a "proprietary" distribution, I don't see that it would be in IBM's interest. There is a signifigant cost investment to be made in supporting an operating system, and recouping that investment when other distributions are available would be nigh impossible.
>This can't be a good thing for linux at all. >Proprietary versions of linux?
The first question here is how exactly you'd make it propritary. The kernel, core libraries, utilities and daemons are all under the GPL.
You can certainly write your own versions of libraries and utilities. And it's nigh trivial to make a compatibility layer in a proprietary Unix kernel. But isn't that what AIX 5L is?
And then you have to wonder how you're going to get any return on investment. Competitive pricing in the Linux world is free. Sure you can make money off support, but you don't need to create a distribution for that.
Even if the pricing isn't a consideration, what reason would there be from a customer standpoint to use a proprietary version? Half of the draw of open source is in its openness - no vendor lock in, no abandonware, the ability to do in house modifications and support, no licence management overhead.
I'm not sure why Sun would be pursuing a custom version of Linux either, and their press releases never say that they are. The only thing that could possibly be interpreted as this is "Sun will ship for the first time a full mplementation of Linux on a new line of general-purpose servers."
Howver, that makes no mention of it being their own version of Linux; just that it will be a full implementation. This is likely to differentiate it from their line of Linux powered server appliances (aquired from Cobalt).
Until they release further details next quarter, its pretty much impossible to do anything but speculate.
>These dual proccessor motherboards both scored >worse in kernel compilations with both >processors active!
And I'd bet you my next paycheck this is yet another example of the poor benchmarks from Tom's Hardware. They don't mention what options were used, but from the results it's pretty clear they just did "make" instead of "make -j2", so the compile was running a single job at a time.
>It was faster to run the kernel compilation on a >single processor.
Let me rephrase that for you - it was faster to run the kernel compilation on a single processor on an single processor kernel, as opposed to running the kernel compilation on a single processor on an SMP kernel.
>While two 32-bit CPUs != 1 64-bit CPU, it does >illustrate how a major hardware change can make >linux (or indeed any OS) flounder around. [
This is pretty much just speculation though. The proof is in the pudding, as they say.
And running 64-bit is hardly new to Linux. You have to set the way back machine all the way to late 1994 if you want to glance at the first efforts to make Linux run on a 64-bit platform. So 7 years of the 10 year history of Linux is as a multi-platform 64-bit capable operating system.
Not only that, but mainframes don't take up a whole room anymore.
The Z/Series starts at a footprint of about 14 square feet and goes up to 30 in a two frame configuration, the S/390 is about 10 square feet, and a 42U rack cabinet is about 7 square feet.
So even if you take the worst case scenario, the "room-sized" perception suddenly shrinks to about the size of four standard racks.
>But some clueless suit bought SVR5 >10 years ago and still can't admit that it was >a big, expensive mistake.
Actually, they bought SVR4; SVR5 wasn't introduced until March 1998, with the release of Unixware 7. To the best of my knowledge, noone has ever bothered to license it.
Slashdot Mirror
>Well, then MySQL is just a server (aka listener)
>to a database toolkit. It doesn't make it as a
>database server iether.
Any MySQL build includes: a listener, a query engine, and a backend. Just because you can change the backend doesn't make it any less of a database server.
Matt
>One comment in the Life After Redhat article stuck
:)
>out. He loves FreeBSD and his systems are
>"upgraded once a week (all software)". Is this
>normal pratice? I still have SuSE 6.3 systems
>running.
"Normal practice" varies depending on who you're talking to.
On the networks I administrate, I have a strict policy of "no unjustified upgrades", which usually translates to applying only security patches and relevent bug fixes. It might include new versions of software if, and only if, we're rolling out an enhancement to our services that necessitates it.
Part of the reason for being so restrictive is because we do QA and testing after every upgrade, so all upgrades have an associated cost in admin time. It may seem overly paranoid, but we've caught a lot of subtle issues that would have otherwise effected service to our customers.
Matt
>If all you want or need is a glorified Berkely DB,
>that's fine -- but stay away from anything
>mission-critical.
This statement doesn't really make any sense, since BerkelyDB is primarily a database toolkit, not a database server. It doesn't even implement SQL or any other quasi-relational language, just programming APIs.
It also implies that BerkleyDB is somehow feature limited, which really isn't the case. It supports transactions with full rollback capability, replication and transparent failover, load balancing, write ahead logging and checkpointing, hot backups, etc, etc.
It might not make sense for a general purpose database, but if you have predictable access patterns, it can seriously rock, particularly if you want to embed database features into an application.
Matt
... that Buffalo invented air conditioning? We're EXPERTS on cold. :)
Matt
>What's Eminem's beef with Moby anyway?
Moby had more than a few words about Eminem at the Grammy awards. Don't feel like getting into an argument about whether he's a homophobe or mysoginist, but the allegations of racism are amusing given his contemporaries.
"He's very good at what he does and he's very clever, but he's also a misogynist, a homophobe, a racist and an anti-Semite... I don't see how I can lend any sort of support to an artist like that."
"OK, well maybe I'm making an assumption. Maybe I'm painting with a broad brush. But do you know that he's not an anti-Semite? I'm pretty sure, I've read interviews where he says something anti-Semitic. In any case, even if he's not an anti-Semite, he's still a racist, a homophobe and a misogynist."
"I was talking to somebody earlier about the notion of Eminem being in the continuum of Elvis Presley, the Sex Pistols, Public Enemy, and Kurt Cobain. But the difference is that they were all rebellious in the sense that they were extending boundaries -- creating culture that broadened people's perspectives. The problem with Eminem is he's creating culture that appeals to the lowest common denominator."
Matt
Actually, the X forwarding stuff isn't a compile time option. It won't work unless you have X installed, of course, but it doesn't break it if you don't.
./configure && make && make install!".
The packages that have options that would cause dependencies (e.g. emacs with X11 support) are in fact often split into different pacakges - emacs-nox and emacs-X11, vim-common/enhanced and vim-X11. Other ones take advantage of software that has modules, such as apache and perl. And a large number of other packages are compiled with optional features enabled, but not turned on in the config files.
Big dependencies (e.g. X, Python, Perl) *are* seperated out into their own packages, and in most cases other features are turned on by default. And once you start looking at desktop level software, configuration is usually done within the application, not compile time. But even when that's not the case, it is often provided with plugins its easy to package on their own (look at GStreamer, the multimedia framework - each codec that has an external dependancy is split out into a seperate RPM so you can install only those features that you actually need).
My main point is that most people *don't* do customization on their software. Remember, the mantra of source code advocates is "but compiling is easy, it's just
I can see the appeal of something that automatically configures itself based on what you have installed, even if I see it being of limited utility. And I can see some issues with it, such as the gentleman who pointed out that in Gentoo, if you compile with a library installed, then remove that library, it will silently break the application.
As for difficulty in custom compiling RPMS, it's really not nearly as difficult as people make it out to be. On a lot of packages, if you do a rpm --rebuild on a SRPM, it runs through a straight configure that detects what libraries are installed, and the find-requires script will write your new RPM with all the proper dependencies.
And if you need to change an implicitely specified option, you can install the source rpm, change the "./configure" line in the spec file, and rpm -ba it.
But most of the time this really doesn't buy you much. I run about 60 Red Hat machines and the only custom RPMs we need is software that was written or modified in house, and the kernel, since there was a particular issue that we needed to patch away (a two line change to the spec file).
Matt
>This is surely due to the various distributions >not conforming to the LSB and FHS, rather than the >shortcomings of the package management system? >Debian is far more standards-complient than >RedHat, and Slackware is even better.
Sorry, but Red Hat's lack of complaince (or lack of willingness to comply) with the LSB is a myth.
These aren't the official results, but preliminary test results at freestandards.org show Red Hat as passing more tests than Debian, SuSE, and Caldera.
Among some of the issues that Debian were that their init scripts didn't provide a status command, and that there was no distinction in runlevels 2-5. I haven't kept up with development too closely, but my Debian installation, which has been apt-get upgraded fairly recently still has these issues.
As for Slack, last word from Patrick Volkerding that I know of is that he's taking a "wait and see" approach; i.e. he's not even bothering to strive for LSB complaince until he's convinced that compatibility is improved between compliant distributions, although to his benefit he said "I'm sure this is a step in the right direction."
I haven't used 8.1 at all, but Slackware probably has the most work cut out for it if they decide to try to move towards LSB compliance - their init levels are non-standard, their init scripts are completely non-standard (kind of a weird hybrid BSD/SysV approach), they fail a good potion of the FHS tests, etc, etc.
In other words, nit picking aside, Red Hat and Deibain are pretty much on par as far as comformance go, and Slackware is way off.
Matt
>Now it's true that Potato (aka Stable) is out of
>date. It's stable as hell, but I don't think any
>desktop user should use it (servers are another
>story, as is often the case). "Testing" has been
>just as stable for me as full releases of >Mandrake and others, that is no crashes. I've
>never used unstable, but hey, I've got a extra
>box lying around here somewhere.
Just to reiterate... SERVERS ARE ANOTHER STORY... I've seen a number of people saying that they keep the servers they admin up to date by putting an apt-get update in cron, and also that they use testing because it's "stable as other distributions".
But I've had serious issues on a home box that I upgraded with the testing branch in a futile quest for more up to date software; e.g.
sendmail was 'upgraded' to store its mail
spool in a different location, without any
clear notification, without moving the mailboxes
or putting in a symlink, without changing any
of the other mail programs to look there...
apache was 'upgraded' to a version that was
compiled with large file support, but didn't
have a dependcy on a kernel that could support
this so it would randomly crash...
for some ungodly reason it decided to install
z-mailer and wouldn't let me uninstall it even
though no packages depended directly on it or
on an mta at all (iirc it required deleting
a symlink somewhere on the system or something)
several of the packages are compiled such that
they are trying to use unimplemented syscalls
(likely compiled against a different variant
of the sun4 architecture than I have)
And those are only the issues that come to mind. I'm still pondering whether I want to give OpenBSD or NetBSD another try, but last I checked their NIS implementation was piss poor.
Matt
>Have you tried doing a minimal install, with ssh,
>but without X?
>
>Actually - I'm kinda bluffing that it won't work
>here, it didn't work on SuSE so I'm assuming it
>won't work on RH either.
Works just fine. Just because two distributions are rpm based doesn't mean they make the same mistakes.
Actually, the only thing that Red Hat makes you install is the "base" package list. Comes to maybe 200MB and contains, IMHO, very little crack rock. About the only things I might be inclined to strip out are slocate (not exactly a good thing on high volume servers with millions of files), gpm and mouseconfig (sixty servers, no mice).
Don't take this as a personal affront, but it constantly amazes me how ungrounded in reality many people's complaints against Red Hat are; e.g. they turn every service on by default, they don't test their software before shipping it, their minimum install is bloated (feel free to take offense at that, if you must), they're not striving for LSB compliance, etc, etc.
There may be some cases where they were guilty in the past, but they've done a more than adequate job of responding to issues when they crop up and are, IMHO, one of the better distributions out there.
Matt
It's really not that hard to figure out:
/usr/src/redhat/RPMS).
/usr/src/redhat
rpm --rebuild whatever.srpm
Your shiny new binary RPM(s) will be in whatever the system path is for RPM (on Red Hat it's
Or alternately, you can
rpm -i whatever.srpm
cd
rpm -ba SPECS/whatever.spec
And the binary RPMs will end up in the same place. Plus with that method is you can edit the spec file for customization.
Most people who gripe about RPMs being too hard probably have never looked at the spec files before - all they are is some meta information and a shell script that builds the program. Building from scratch may be hairy for a new user, but customizing an existing package is REALLY easy; usually it's just a matter of looking for a line starting with "./configure" and adding the options you want after that.
Why go through the trouble when you could do it from source? It is much much easier for replicated installs, you don't have to worry about stray files lying all over the place, its easy to tag files as being configuration so they don't get overwritten, etc, etc.
Matt
>What type of research has Redhat funded for the
>sake of Linux?
Well, they employ:
Owen Taylor - one of the maintainers of GTK+
and the author of Pango
Havoc Pennington - author of GConf, Metacity
Jonathon Blandford - maintains the Gnome Control
Center, contributed to GTK+
Elliot Lee - wrote ORBit, works on embedded
GTK+
Dave Mason (until a couple days ago) - GNOME
documentation
Steve Tweedie - ext3
Alan Cox - kernel hacker extrodinaire
Not to mention the projects they contribute to:
GCC - remember Cygnus? remember who bought them?
CygWin - see above
eCos - see above
EL/IX - see above
newlib
tux
insight
mauve
source-navigator
pirahna
Aside from that they do a *lot* of testing and bug fixing on everything in the distribution.
Matt
>Oh, I don't know. Maybe the fact that Amazon
>doesn't actually create the products they
>facilitate the sale of, used or new.
Car dealerships manufacture their own cars now?
>Maybe the fact that used car sales are an
>essential component of marketing new cars (the
>trade-in market). So much so that many
>manufacturers have their own "certified" used car
>programs.
And it's far from unlikely that people who are selling books on Amazon and E-bay won't use some of the profit to buy more books. I myself do this.
So the analogy isn't perfect. None are. But the point is that the transaction happens with no benefit to the original seller because they already sold it.
Matt
>Everyone who cares about network transparency and
>X and legacy unix apps, the first thing they say.
>
>You guys use linux because its a job, i bet you
>use windows at home, I use linux as my primary
>desktop, at HOME.
As other pe ople have pointed out, you lose.
I've been running Linux at home since 1995. By 1996 I wiped out my Windows partition.
Now I've got three machines running Linux, one running OpenBSD, and have machines running HP/UX and Solaris on the way.
Guess what - only one of my machines has a monitor on it.
Matt
>Some day is now. Xenix became SCO UnixWare became
:). This release did include some features designed to ease transition from Openserver 5, but it was an evolution of the SVR4.2 codebase of Unixware, NOT the SVR3.2 codebase of Xenix.
>Open UNIX 8 [caldera.com].
Not quite.. As I pointed out in an earlier post Xenix became SCO UNIX which became SCO Openserver. It was originally based on V7, and later SVR2 and SVR3.2, with features from SVR4 either backported or reimplemented when it became Openserver.
Unixware was an SVR4.2 implementation SCO aquired from then owner Novell. It was sold pretty much unchanged as Unixware 2.x for several years.
In 1998 they released Unixware 7, which was touted as being the first SVR5 implementation. Since SCO now controlled the Unix codebase, they could bump the version number
The closest thing to a remaining relative would be Openserver 5.0.6, which is still marketed by Caldera.
Matt
Maybe you're just unlucky :) I worked support at a large company, mostly on Unix systems. So I've walked people through SCSI configurations on HP/9000s, Sparcs, Vaxen, Alphas, PeeCees, Macs running HP/UX, SunOS, Solaris, Digital Unix, OSF/1, Openserver, Unixware, SCO 3.2v4.2, Xenix, Linux, FreeBSD, Windows, MacOS... I think the only really weird problem I saw beyond driver issues was one machine which would only work unterminated.
I any case, its not perfect, but considering the SCSI standard deals with a mish-mosh of signaling, ranging from 5MHz to 80MHz, single ended or differential, 8 or 16 bit, single or double pumped, synchronous or asynchronous operation... Not to mention various extentions to the protocal including packetized scsi, domain validation, etc, etc...
Honestly, I'm amazed that they've managed to push the speed up well over 100x what the original 8-bit narrow async standard pushed, and you can still slap on an adapter and have a damn good chance of it working.
Matt
>Other than the touted 600Mb data rate versus 400Mb
>for FireWire [apple.com],
It's 600MB, not 600Mb, and that's in a future revision. The initial devices will be 150MB vs 400Mb on firewire, or about three times faster than firewire.
Matt
>to compete with the firewire (and upcoming
>gigawire) "standard" and the usb 1.x and 2.x
>"standards". oh and we have ata/133/100/66
>"standards". scsi
>1/2/3/4/5/ultra/wide/thin/mega-super-fun
>"standards" too.
>
>how come none of my "standard" devices talk to
>each other very well?
How do SCSI devices not talk to one another well? I've run SCSI-1 devices on Ultra2 controllers and vice versa without a single glich. Likewise, I've run ATA/33 devices on ATA/100 controllers and vice versa without a single glich.
I have little experience with either USB or Firewire, but I've never heard of problems with backwords compatibility on either of them.
Matt
>Eventually Linux might have this feature ... yet
>more evidence that *bsd is years ahead of linux
No, its evidence that you don't know what you're talking about. Linux has supported immutable and append-only flags since the 1.1 series of kernels, way back around 1994.
Matt
>Okay, let me be sure I understand this - Miguel .NET - which
>and his gnomies wanna base GNOME on MONO which \
>is an open source implementation of
>was developed to compete with Sun's Java - and
>Sun's throwing developers at this?
A few things:
The only developer who has said they are interested in making Gnome "based on" Mono is Miguel. Your inclusing of "and his gnomies" seems to imply that this is a widespread intention; it is not.
The term "based on" is misleading. As Miguel himself said:
Rewriting GNOME in C# with the CLR would be a
very bad idea, if not the worst possible idea
ever.
And furthermore Mono is being based on Gnome technologies, not the other way around:
Libart will be used to implement the
Drawing.2D API; Gtk+ and the GNOME libraries
will be used to implement the WinForms API and
of course Glib and libxml will be used in
various places
If anything, it would be more accurate to say that Mono is being offered as an alternate API for accessing the Gnome libraries, and that Miguel has belief that this API offers signifigant enough advantages that future code may be based on Mono, or embed the Mono runtime.
The next thing is that this has nothing to do with Gnome 2.0, which is the project that they will be working on. Miguel stated he would like to see Gnome 3.0 have Mono ties, but he has also stated that his guess is that Gnome 4.0 would be when developers start seeing the benefits of it.
And of course, the more important point - Miguel does not have maintainer control over ANY package in Gnome. He has long since given maintainership on every project he worked on to someone else.
What this means is that the only thing that will move Gnome to dependency on Mono is if it is reached as a consensus among the Gnome developers.
Matt
There is a black and white issue here. Distributing copies of a copyrighted work without the permission of the "author" is illegal. However, in my opinion, it is far from being in the publisher's best interest to take action against the distribution of abandonware titles.
:)
The questions they should be asking themselves are:
1) Does this harm us?
2) Can we capitalize on this?
The first question pretty much comes down to two key issues - is there loss of revenue, and does it dilute intellectual property.
Unless there are ongoing efforts to sell a particular title, it is not generating a revenue stream. This is pretty straight forward.
There may be a question as to whether it could be used to generate a future revenue stream; e.g. via the release of "classic" packs. This, however, is not feasible in a games current form unless it runs on a currently available platform.
So, in terms of revenue, the publisher is out of luck unless it runs on Windows or Macintosh. They may do an port of older games, but that depends on a value add in order to make it a sellable asset.
The second issue - protection of intellectual property - is pretty much a red herring. These are not trademarks; no matter how many times someone illegally copies them, it will not prevent them from successfully enforcing copyright on them in the future.
So onto the second question - can this be capitalized on? The answer here is a resounding YES.
The biggest benefit of abandonware, illegal or not, is that it helps maintain a franchise. If there is any question of the value of having a well known, wide spread franchise, one only need look at Ninetendo.
There is also a lot of good will to be culled from releasing old games (in their current form, not applicable to future releases) under a free beer license.
What my suggestion to publishers would be is to release these games under a license allowing free play, but not free redistribution, and then license redistributions rights to abandonware sites, not for money, but for advertising space.
When applicable this would make an ideal launching pad for advertising updates of old classics, or new games in a series, as it targets the people who loved the originals enough to go searching for them.
Of course, this is only my opinion, and doesn't count for jack in the real world
Matt
>ok, i'll bite, smart-ass
s /s 390/
Again with the epithets. This hardly gives confidence in the strentgh of your arguments.
>Suppose that I want to migrate one x86 linux
>server (for example Mandrake 7.2 based, which
>runs Oracle 8i well) to a s/390 VM. Will it be
>easy because there is MDK for the s/390? I doubt
>it.
Well, before I address that, I quote your original post:
the mind boggles... do you really believe that
Mandrake or RedHat will install on the s/390?
The question has nothing to do with whether it would make anything easier, just whether it will install. Which it will.
As for whether it would be make the port any easier? On Mandrake, no, as it has no S/390 port.
However, Oracle, like most of the ISVs that have released software for Linux/390, support SuSE exclusively, as they had the first comprehensive commercially supported distribution for the S/390.
Even if you're not using a commercially supported product such as Oracle, there is a distinct advantage to being able to utilize the same platform on the S/390 as your current Intel machines. The most obvious one is retraining, integration with current systems (e.g. patch management), and ease of porting (yes, some software needs to be "ported" between distributions, due to different versions of compilers, libraries, and directory layout).
>SUSE's say it includes XFree (I wonder how X can >run on an s/390... but I may be talking my ass >here since the last MF I worked on was an old >3090)
The same way it runs on headless servers - remotely, either on an application by application basis, or through XDM.
>Turbolinux asked me to register to see more >stuff,so I ditched it. what kind of freak use >that anyway?
Not for me to say, but they have a signifigant customer base.
>Debian is beta, but it is promising. Debian
>dudes are serious, but their attitude kinda
>kills them in the corporate world. no
>proprietary software? haha, dream on.
Personally, I've not been happy with the Debian boxes I've had to administer. However, there are a signifigant number of companies running it.
>Red Hat's look like vapourware to me.
Most vapourware isn't available for download:
ftp://ftp.redhat.com/pub/redhat/redhat-7.2-en/o
>So, don't be so touchy, you sissy. Any serious
>production environment of linux on s/390 will
>use an IBM's blessed distro, not that crap.
I actually had a S/390 onsite for evaluation last year. Do you know what distribution IBM recommended? SuSE.
Do you know why? IBM doesn't have a Linux distribution. They have a set of kernel patches available to support the S/390, and links to Red Hat, SuSE and Turbolinux.
Matt
>The alarming thing is that they are producing
>their OWN version of Linux, not using Redhat or
>another company. And also IBM I understand is
>doing this too.
IBM has actually done a commendable job of keeping their support for Linux as vendor agnostic as possible, while still working with Red Hat, SuSE and TurboLinux for more comprehensive services.
Though, not being an IBM executive, I cannot rule out the possibility of a "proprietary" distribution, I don't see that it would be in IBM's interest. There is a signifigant cost investment to be made in supporting an operating system, and recouping that investment when other distributions are available would be nigh impossible.
>This can't be a good thing for linux at all.
>Proprietary versions of linux?
The first question here is how exactly you'd make it propritary. The kernel, core libraries, utilities and daemons are all under the GPL.
You can certainly write your own versions of libraries and utilities. And it's nigh trivial to make a compatibility layer in a proprietary Unix kernel. But isn't that what AIX 5L is?
And then you have to wonder how you're going to get any return on investment. Competitive pricing in the Linux world is free. Sure you can make money off support, but you don't need to create a distribution for that.
Even if the pricing isn't a consideration, what reason would there be from a customer standpoint to use a proprietary version? Half of the draw of open source is in its openness - no vendor lock in, no abandonware, the ability to do in house modifications and support, no licence management overhead.
I'm not sure why Sun would be pursuing a custom version of Linux either, and their press releases never say that they are. The only thing that could possibly be interpreted as this is "Sun will ship for the first time a full mplementation of Linux on a new line of general-purpose servers."
Howver, that makes no mention of it being their own version of Linux; just that it will be a full implementation. This is likely to differentiate it from their line of Linux powered server appliances (aquired from Cobalt).
Until they release further details next quarter, its pretty much impossible to do anything but speculate.
Matt
>These dual proccessor motherboards both scored
>worse in kernel compilations with both
>processors active!
And I'd bet you my next paycheck this is yet another example of the poor benchmarks from Tom's Hardware. They don't mention what options were used, but from the results it's pretty clear they just did "make" instead of "make -j2", so the compile was running a single job at a time.
>It was faster to run the kernel compilation on a >single processor.
Let me rephrase that for you - it was faster to run the kernel compilation on a single processor on an single processor kernel, as opposed to running the kernel compilation on a single processor on an SMP kernel.
>While two 32-bit CPUs != 1 64-bit CPU, it does
>illustrate how a major hardware change can make >linux (or indeed any OS) flounder around. [
This is pretty much just speculation though. The proof is in the pudding, as they say.
And running 64-bit is hardly new to Linux. You have to set the way back machine all the way to late 1994 if you want to glance at the first efforts to make Linux run on a 64-bit platform. So 7 years of the 10 year history of Linux is as a multi-platform 64-bit capable operating system.
Matt
>buys a single cpu room sized mainframe
Not only that, but mainframes don't take up a whole room anymore.
The Z/Series starts at a footprint of about 14 square feet and goes up to 30 in a two frame configuration, the S/390 is about 10 square feet, and a 42U rack cabinet is about 7 square feet.
So even if you take the worst case scenario, the "room-sized" perception suddenly shrinks to about the size of four standard racks.
Matt
>But some clueless suit bought SVR5
>10 years ago and still can't admit that it was
>a big, expensive mistake.
Actually, they bought SVR4; SVR5 wasn't introduced until March 1998, with the release of Unixware 7. To the best of my knowledge, noone has ever bothered to license it.
Matt