Munich now Open Source

[runderwo]

Gurm:

"You can quibble if you want. The N64 emulators out there now don't REALLY emulate the N64 architecture. They take the same function calls and return the same results from those function calls. That makes them... not REALLY emulators. Just like WINE."

Did you know the N64 uses a MIPS microprocessor? It also has no MMU, a custom video processor, etc. It's a completely different architecture to x86 which is in most people's desktop computers. It also has no operating system kernel, only a set of library functions that provide pseudo-OS functionality. There is no way you can accurately replicate the functionality of the N64 on a PC without keeping track of the entire state of the hardware of the machine and every change to it in software. That is emulation. Porting a software API to another system is not emulation.

Pace:

"I completely fail to see how running Windows applications in Linux is advantageous to most people."

It means not having to reboot to play a game, or being able to use a low cost operating system on computers where Windows software is required to access e.g. special hardware or perform very specific functions. We see this a lot at my university.

It is not advantageous to most people, because most people don't run Linux and the state of the WINE project is still rather alpha. I am glad it is happening because, as you say, it makes the OS irrelevant and allows the user to run his apps wherever and whenever he chooses.

"So, will a flaky, badly coded, Windows app run better using WINE?"

It might run better than its corresponding flaky, badly coded Linux app 8)

I use WINE mainly to check that my servers operate correctly against Windows client software. I'm a Transgaming subscriber but I've been too lazy to even bother downloading the latest releases. Any step towards loosening Microsoft's grasp and giving users an easier way out, if they should choose, is one step further towards an open and competitive market for computer software.

[Gurm]

Originally posted by runderwo
Did you know the N64 uses a MIPS microprocessor? It also has no MMU, a custom video processor, etc. It's a completely different architecture to x86 which is in most people's desktop computers. It also has no operating system kernel, only a set of library functions that provide pseudo-OS functionality. There is no way you can accurately replicate the functionality of the N64 on a PC without keeping track of the entire state of the hardware of the machine and every change to it in software. That is emulation. Porting a software API to another system is not emulation.

Are you done? The first N64 emulator was FAR too small to be a real emulator. No state machine, no BIOS, no nothing. I didn't think it would work either, but it did. Later emulators came out, approached in a more traditional manner. I'd love to know how the first group did it, though.

It means not having to reboot to play a game, or being able to use a low cost operating system on computers where Windows software is required to access e.g. special hardware or perform very specific functions. We see this a lot at my university.

If you need Windows to do specific hardware access... I'm kind of doubting that it's gonna run real well under WINE. Unless that hardware runs on a very simple, general port. Things that plug into the parallel port I could see. Things that run over USB or FireWire or SCSI... not so much. I mean hey, you might be able to prove me wrong. But if it's so specialized that nobody has written a Linux proggy to access it, it's probably too specialized to run under WINE.

As for games... umm... what games worth playing run under WINE? I can't possibly imagine that either DirectX or OpenGL work properly under it. That rules out 99.99% of games released today.

It is not advantageous to most people, because most people don't run Linux and the state of the WINE project is still rather alpha. I am glad it is happening because, as you say, it makes the OS irrelevant and allows the user to run his apps wherever and whenever he chooses.

Don't get me wrong. I'm glad someone is writing this program. I just find it irrelevant in my daily life. I have for... err... God, like 10 years. Is WINE really that old? Yeah I think it is. Damn.

"So, will a flaky, badly coded, Windows app run better using WINE?"

It might run better than its corresponding flaky, badly coded Linux app 8)

But not better than it does under Windows, with the possible exception of MAYBE not taking the whole machine with it when it crashes. Which I concede as a benefit of this process. A slim one at best.

I use WINE mainly to check that my servers operate correctly against Windows client software. I'm a Transgaming subscriber but I've been too lazy to even bother downloading the latest releases. Any step towards loosening Microsoft's grasp and giving users an easier way out, if they should choose, is one step further towards an open and competitive market for computer software.

I agree with you, but I find this statement ironic and funny. You want a competitive market for software, and hope to achieve it through an OS which is solely dedicated to free software?

Umm...

- Gurm

[runderwo]

heh:

"Are you done? The first N64 emulator was FAR too small to be a real emulator. No state machine, no BIOS, no nothing. I didn't think it would work either, but it did. Later emulators came out, approached in a more traditional manner. I'd love to know how the first group did it, though."

Am I done what? Am I making you mad? :P

You are correct in that UltraHLE was not a complete emulator. It was a CPU emulator with reimplemented libultra -- when the game made a call to a known libultra function the emulator simply jumped to its own code which implemented parts of libultra. Consequently, the compatibility was quite low because not only were the libultra re-implementation somewhat incomplete, but also because not all games used libultra, many rolled their own libraries and replacement functions because they found the pseudo-OS to be lacking for their needs.

Current N64 emulators are far more complete emulators of the N64 machine, and thus require a heftier machine to achieve a decent framerate but allow for higher compatibility with programs that would use hardware features directly.

"If you need Windows to do specific hardware access... I'm kind of doubting that it's gonna run real well under WINE."

Doubt all you want, or you could read the documentation and find out that WINE will redirect hardware port I/O accesses to the C library as well (inb, outb)

"Unless that hardware runs on a very simple, general port. Things that plug into the parallel port I could see. Things that run over USB or FireWire or SCSI... not so much. I mean hey, you might be able to prove me wrong."

No, WINE doesn't have USB or Firewire stacks, or SCSI hardware support. Those would require kernel mode to be used efficiently. The rule is that any hardware that is to be used in WINE must be supported by the underlying operating system so that WINE may remain a completely user-space and relatively thin API. However, it does have an ASPI implementation so things like cd-burning or ripping software work correctly.

"But if it's so specialized that nobody has written a Linux proggy to access it, it's probably too specialized to run under WINE."

Not so, many scientific instruments have protocols that aren't necessarily complicated, but that only the program that comes with them knows; and since very few people have to deal with a particular instrument, it would not be worthwhile to sniff out traffic, reverse the protocol, and write a new implementaiton, especially when the people using it aren't programmers and have more important things to do!

"As for games... umm... what games worth playing run under WINE? I can't possibly imagine that either DirectX or OpenGL work properly under it. That rules out 99.99% of games released today."

I'm not going to do anymore research for you, but suffice it to say that you are wrong. Wine has excellent OpenGL support, (examples: Half-life, Unreal, Quake) and Transgaming was formed specifically to develop further the DirectX API support in their product WineX and make Wine more usable for playing games. They have mostly complete D3D 7 and 8 support which runs many of the newest games on the market.

"Don't get me wrong. I'm glad someone is writing this program. I just find it irrelevant in my daily life. I have for... err... God, like 10 years. Is WINE really that old? Yeah I think it is. Damn."

Well, even if you don't use it, it is an open door out of Microsoft lock-in that many people are using for a plethora of purposes. Consequently, trashing it at every opportunity just because you don't use it makes you look foolish to anyone who has received any benefit at all from WINE.

"But not better than it does under Windows, with the possible exception of MAYBE not taking the whole machine with it when it crashes. Which I concede as a benefit of this process. A slim one at best."

How do you know that WINE's implementation of a particular Win32 API set that a program uses isn't better than Microsoft's? Or is this more divination :P

"I agree with you, but I find this statement ironic and funny. You want a competitive market for software, and hope to achieve it through an OS which is solely dedicated to free software?"

A competitive market is about the consumer having choice. When the user depends on an application that only runs on Win32, he has no choice in operating system if WINE doesn't exist and thus it's a rigged game in Microsoft's favor. Since WINE does exist, he can try to get it running with WINE instead; it might work great, if it doesn't, the developers can be made aware that people are using this particular application and work towards making the libraries more compatible for that app.

I don't see irony in the previous statement. "Free software" implies a freedom to modify and redistribute software that you have received either through purchase or gift. It does not imply that you received this software "gratis" or for no cost. There is a lot of free operating systems all with their different feature sets, some commercial, some non-commercial, some freely downloadable, others not, all competing with each other and with proprietary vendors like Microsoft. The user having a choice to pick from all of those, as opposed to picking from Microsoft only, is the essence of a competitive marketplace; since he can decide which system he likes better based on a broad feature set, and not just "I need to run this program and because of API lock-in I can only use Windows for it".

[Pace]

Originally posted by Gurm
As for stability... a flaky, badly coded Windows app will, in THEORY, not crash the Linux kernel when running under WINE. However, it has been known to happen regardless, since Linux is nowhere NEAR as "stable" as everyone would like you to think it is. In fact, my Linux box will often crash for no good reason other than "Mandrake is having a bad day".

I was meaning the stability of the app, I would like to think the OS would not be affected

Originally posted by runderwo
It means not having to reboot to play a game, or being able to use a low cost operating system on computers where Windows software is required to access e.g. special hardware or perform very specific functions. We see this a lot at my university.

It is not advantageous to most people, because most people don't run Linux and the state of the WINE project is still rather alpha. I am glad it is happening because, as you say, it makes the OS irrelevant and allows the user to run his apps wherever and whenever he chooses.

"So, will a flaky, badly coded, Windows app run better using WINE?"

It might run better than its corresponding flaky, badly coded Linux app 8)

I never have to reboot to play a game.

Define a low-cost OS. I can have a fully working Windows 2000 box up and running well within 2 hours. That is what I call low cost

[runderwo]

Pace

"I never have to reboot to play a game."

That's nice. (?) After all, that is one of the convenient things about using the most popular operating system. Unfortunately, it's not so rosy for me because if I want to play a game that doesn't work well with WINE or doesn't have a native port, it's either reboot into win98 or nothing. A native port for any software older than a year with no source code is essentially hopeless, which is a major driving force behind WINE development; it's the only way to remove the Windows dependency in that case.

"Define a low-cost OS. I can have a fully working Windows 2000 box up and running well within 2 hours. That is what I call low cost"

Cost is for example a $200+ operating system license spread across 500 computers. For some, that is worth it, but it is nice to actually have a choice in the matter and not have it be dictated by the API that your application developers chose when they coded their crappy, but essential for your uses, program. If that $200 x 500 is worth it to you for the convenience then go for it! On the other hand, educational institutions and government rarely can afford it, especially when they have people working for them at typically fairly low rates that can work around the inconvenient parts of the alternative choices.

For a home user (especially one that most likely pirated their copy of windows) the cost argument is somewhat hollow.

[Slougi]

Gurm
I in fact know many n64 emu coders, like hacktarux (mupen64), jabo and tooie (pj64), rice and schibo (1964) and icepir8 (tr64). I chat with them almost daily. I can tell you that comparing current n64 emulators and wine is like comparing apples and oranges. Today's n64 emulators are almost completely low level emulators with recompilers for both the main CPU and the RSP. The only high level emulated part that remains is graphics. Wine on the other hand does nothing than reimplement the various windows apis, which is similar to how high level emulation works. The difference is that wine does not need to emulate the CPU on x86 machines, nor does it need to emulate things like serial ports or OpenGL.

OK, now we got that out of the way.

As for games... umm... what games worth playing run under WINE? I can't possibly imagine that either DirectX or OpenGL work properly under it. That rules out 99.99% of games released today.

Let's see... one game I run frequently is jedi knight 2, and I also run heroes of might and magic occasionally. Most opengl games work completely, as well as many of the older directx games. Winex has better support for directx, but the copy protection costs money. Codeweaver's stuff on the other hand has increased support some of the core windows apis and thus it runs for example PS7 and renders IE completely correctly (in regular wine the buttons are black).

But for example MS Office runs perfectly in wine, if you happen to need it. So does much of visual studio. I have to say I have never needed either, but that is beside the point.

Personally, the only thing I run under kazaa is the two games mentioned above, as well as kazaa. Now that I have discovered gift and it's plugins I am not really using kazaa, since I have a native Linux app.

[Gurm]

Originally posted by runderwo
Am I done what? Am I making you mad? :P

Presuming, as a 40-post mini, to "educate" me about what an emulator is or isn't. I know. I've written them (I worked on a couple of the more popular original SNES emulators).

You are correct in that UltraHLE was not a complete emulator. It was a CPU emulator with reimplemented libultra -- when the game made a call to a known libultra function the emulator simply jumped to its own code which implemented parts of libultra. Consequently, the compatibility was quite low because not only were the libultra re-implementation somewhat incomplete, but also because not all games used libultra, many rolled their own libraries and replacement functions because they found the pseudo-OS to be lacking for their needs.

Yup. Compatibility was low, but it ran Mario64 which was more than the "real" emulators could do for 2 years after UltraHLE came out.

Current N64 emulators are far more complete emulators of the N64 machine, and thus require a heftier machine to achieve a decent framerate but allow for higher compatibility with programs that would use hardware features directly.

Ayuh. And eventually WINE _will_ implement special-casing for low-level access and/or programs that are written in Assembly and use non-standard calls. And then it will slow down.

Doubt all you want, or you could read the documentation and find out that WINE will redirect hardware port I/O accesses to the C library as well (inb, outb)

Good. I'm glad the documentation says that. Really I am. Now show me working sound code for games that don't use DirectX. Show me working DOS4/GW support. Show me how to run my games that are more than a year or two old under Linux. Go on.

No, WINE doesn't have USB or Firewire stacks, or SCSI hardware support. Those would require kernel mode to be used efficiently. The rule is that any hardware that is to be used in WINE must be supported by the underlying operating system so that WINE may remain a completely user-space and relatively thin API. However, it does have an ASPI implementation so things like cd-burning or ripping software work correctly.

And there are already perfectly good burning packages for Linux, with a few minor exceptions. Otherwise, you're SOL on hardware support. That's basically what you're saying, right? Glad we could clear that up.

Not so, many scientific instruments have protocols that aren't necessarily complicated, but that only the program that comes with them knows; and since very few people have to deal with a particular instrument, it would not be worthwhile to sniff out traffic, reverse the protocol, and write a new implementaiton, especially when the people using it aren't programmers and have more important things to do!

Like needlessly forcing Linux onto people despite its inherent lack of support and difficulty of use? (*ahem* sorry couldn't resist)

I _said_ that anything on the Serial or Parallel ports would work fine, didn't I? Obviously. But anything with a SPECIALIZED interface won't work. Most of the scientific equipment that the lab I worked for (which had a $100 million grant to do combination sensing and imaging - have you seen the 3D color ultrasounds? That was them...) used required VERY specialized hardware that ONLY ran with Windows drivers, and WINE was no good. I know it was no good because all the "tried and true" Linux users (Lusers) came to me asking for Windows boxes to run their sensing hardware on after they couldn't get it to work under WINE.

I'm not going to do anymore research for you, but suffice it to say that you are wrong. Wine has excellent OpenGL support, (examples: Half-life, Unreal, Quake) and Transgaming was formed specifically to develop further the DirectX API support in their product WineX and make Wine more usable for playing games. They have mostly complete D3D 7 and 8 support which runs many of the newest games on the market.

Many of the newest games on the market don't run under WINDOWS (separate rant, we can get into this another time or you can visit the flamethrower). I fail to believe that if I fire up C&C: Generals, which runs like ass on 50+% of PC's, or Unreal2 which runs like ass on 99% of PC's, that it will run properly (or AT ALL) under WineX. Sorry.

Well, even if you don't use it, it is an open door out of Microsoft lock-in that many people are using for a plethora of purposes. Consequently, trashing it at every opportunity just because you don't use it makes you look foolish to anyone who has received any benefit at all from WINE.

No, it really doesn't. I know people that have received "benefit" from using Macintosh computers. That doesn't mean that I'm not going to MOCK them as hard as possible at every opportunity for being hideous little machines designed for 2-year olds with ADD.

How do you know that WINE's implementation of a particular Win32 API set that a program uses isn't better than Microsoft's? Or is this more divination :P

Two reasons.

1. I've used it.

2. If it ran ANYTHING _better_ than Windows, it'd be all over the friggin' net. They'd be trumpeting the news from the treetops. But... it doesn't, so they aren't. When it does, we'll ALL know about it because you won't be able to go anywhere online without hearing about it. Lusers are like that.

A competitive market is about the consumer having choice.

Consumers have choice. They consistently do NOT choose Linux. They also didn't choose OS/2 Warp, which was a VASTLY superior Operating System. They didn't choose the Amiga, despite it being lightyears ahead of the competition. What MS-bashers and Windows detractors consistently refuse to face is that the consumer has CHOSEN Microsoft. They didn't start off as an evil empire with the ability to buy public opinion. They got where they are by having a BETTER PRODUCT.

When the user depends on an application that only runs on Win32, he has no choice in operating system if WINE doesn't exist and thus it's a rigged game in Microsoft's favor. Since WINE does exist, he can try to get it running with WINE instead; it might work great, if it doesn't, the developers can be made aware that people are using this particular application and work towards making the libraries more compatible for that app.

Let's say I'm a developer. I develop for Windows. Now someone comes along and can't run my app under WINE. If I was unwilling to port the app to Linux in the first place, what on GOD'S GREEN EARTH makes you think, in your dark and twisted little mini mind, that I WOULD be willing to debug/port the application to WINE? Or change the way it works, and the library calls it makes, in order to further its operation on a platform that I refused to support in the first place?

Your logic is specious. You assume that ALL developers would support Linux if only they knew how wonderful it was, or had more time/resources. Guess what? Some developers don't WANT to code for Unix. God knows there's a lot of money in it. I used to be a Unix programmer. You can make so damn much money selling even half-assed software for Unix that it'll blow your mind. But it sucks, so I stopped doing it.

I don't see irony in the previous statement. "Free software" implies a freedom to modify and redistribute software that you have received either through purchase or gift. It does not imply that you received this software "gratis" or for no cost.

Umm, yeah it does. When I hear the phrase "free software", I do NOT think of a gift or modifiable software. I think of software that costs no money. To be sure, there are LOTS of freeware apps out there that are WONDERFUL, better than their commercial counterparts. But not all.

There is a lot of free operating systems... blah blah insert claptrap about the "different" Linux OS'es here.

A lot? Like what? Linux, BSD, and... I'm waiting. Oh wait, you're counting Debian and Mandrake as separate OS'es. Guess what? They're both Unix. In fact, BSD is ALSO Unix. So really it's just ONE OS, now isn't it?

Yeah I'm being a doink. But so are you. You're trying to "enlighten" me as to the nature of open source. I KNOW the nature of open source, and reject it.

- Gurm

[Gurm]

Originally posted by runderwo
Pace

"I never have to reboot to play a game."

That's nice. (?) After all, that is one of the convenient things about using the most popular operating system. Unfortunately, it's not so rosy for me because if I want to play a game that doesn't work well with WINE or doesn't have a native port, it's either reboot into win98 or nothing. A native port for any software older than a year with no source code is essentially hopeless, which is a major driving force behind WINE development; it's the only way to remove the Windows dependency in that case.

You're assuming that everyone WANTS to remove the Windows dependency. I don't. Windows runs great on my machine. Better than Linux ever could. Why would I want Linux ports of games that run under Windows? I run Linux solely as a server/workstation OS - which is where it belongs! My gaming and primary work rig is Windows XP... which I can ALSO have up and running in under 2 hours, for less than $100 a whack... see below.

"Define a low-cost OS. I can have a fully working Windows 2000 box up and running well within 2 hours. That is what I call low cost"

Cost is for example a $200+ operating system license spread across 500 computers. For some, that is worth it, but it is nice to actually have a choice in the matter and not have it be dictated by the API that your application developers chose when they coded their crappy, but essential for your uses, program. If that $200 x 500 is worth it to you for the convenience then go for it! On the other hand, educational institutions and government rarely can afford it, especially when they have people working for them at typically fairly low rates that can work around the inconvenient parts of the alternative choices.

Even XP Pro is much less than $200 per if you're licensing 500 copies.

And the support costs are low. One tech can support hundreds of machines running XP or 2k (I've done it). When something doesn't work, you call the manufacturer or Microsoft and they help you fix the problem.

When you run Linux, and have a problem... well, if your tech doesn't know the solution to THIS SPECIFIC PROBLEM... he has to go online and hunt for it. Now, if you were to make the mistake of going to Mandrake's page and asking for help, you might get an official Mandrake tech on chat, who will tell you...

"If you can't figure this out then you're an idiot and a loser. I'm not going to waste my time explaining something like this to you."

This is an ACTUAL response I received to a perfectly civil (and complex) question about the way that Mandrake's GUI apps modify your system settings. I _still_ haven't found a solution to the problem. I worked around it by changing my hardware around so that Mandrake's app couldn't find it anymore. I get lots of errors, but the issue is "fixed". Great solution, huh?

For a home user (especially one that most likely pirated their copy of windows) the cost argument is somewhat hollow.

Now you're being stupid. You assume that home users pirate Windows? It's FAR more likely that they're working with whatever Home/OEM copy of XP came with their machine. And machines costs are ABSURDLY low right now. Who cares if you have to spend $1000 for your rig WITH Windows XP, or $975 for the same rig WITHOUT Windows XP?

- Gurm

[Gurm]

Oh, and before anyone goes saying "Linux isn't Unix!" (I can hear you whine now), let's not forget that the courts apparently think it is... enough so to award preliminary injunctions to SCO against Linux makers.

- Gurm

[Neptune]

Gurm, are you on MS payroll or something? Because I find it hard to believe that someone not on MS's payroll loves so much to bash and intimidate the people that volunteer on opensource projects, the projects themselves and the people that use them.
And if you are incapable of properly setting up a kiddie distro like Mandrake, then you'd better stop acting like an IT guru in these forums, 'cause you don't have the skills.
You don't like opensource software? That's fine, don't use it. But don't attack the people that create it or use it just because they don't do things your way.
I do contribute to some opensource projects from time to time and I hate to be called "Luser".
Show some respect at least to the OSF developers and their motives. We are not doing it for money or world domination. We do it for your own good (if no OS breaks M$ monopoly, then their prices will be much higher in the future than they are now), even if you don't get it.

[dbdg]

Linus is not going to reduce the price of Windows software by any great margin.

They are two different markets, people who want to set a system up quickly and use software on it and people that want to arse around for ages getting a system working and then tweak it a little more so that it will try and do what you would with the Windows system. [Obviously ignoring the whole server market]

[Gurm]

Neptune:

Listen, mini. I'm not on anyone's payroll. I'm just sick and F-ing tired of everywhere I turn online people are bashing MS's operating systems and software, despite the fact that it WORKS.

And yeah, if a KIDDIE DISTRO like Mandrake can stymie me at times (despite the fact that I have worked on REAL UNIX systems for the past... 12 years) then Linux is REALLY REALLY REALLY a complete sack of shit.

Wanna know what the problem was? The problem was/is that when you set up Internet Connection Sharing from within Mandrake's graphical tools, it sets up smoothwall. No problem, right? Well, even if you disable smoothwall, disable ICS... every time you boot KDE it will F**K up your network connections. And, in typical Linux fashion, the ICS "wizard" has no "disable" option.

So I updated it. The new version has a "disable" option - which is completely ignored.

So I politely ask how to disable this WITHOUT neutering their other tools. I could have just commented out the entries in the config files that call their tools. It's what I ended up doing. But I asked, figuring "hey I can't be the only one that this messes up for". And what did I get? Some Luser on the Mandrake PAYROLL... someone who does support FOR A LIVING... telling me to F*** off because I'm too stupid to use Linux.

Oh really? I'm on the contributor list for Minix. I've written OS'es before. I've tweaked and improved OS'es. I wrote a version of Apple DOS that ran 3 times as fast on Disc accesses as Apple's own. I can write assembly on 8 different platforms, and I've been programming since I was 5. But apparently I'm too stupid for him to bother to explain how to ****ING DISABLE HIS PIECE OF SHIT GRAPHICAL TOOL.

I don't have time to figure it out. I spent a coupe hours looking for the file where the settings are stored. I'm sure it's there somewhere, but I can't ****ing well find it, and after a couple hours of my time... it just isn't worth it anymore. I neutered their entire toolkit, and good riddance.

So don't talk to me about "kiddie distros", because you're full of it. And in my experience, this ****OLE at Mandrake is pretty typical of OpenSource types. You ask a reasonable question and they tell you how stupid you are.

I think the head of the Mozilla project summed it up the best when he said, mockingly, of the head of Konqueror development:

"'Even though some of us used to work on Mozilla, we have to admit that the Mozilla code is a gigantic, bloated mess, not to mention slow, and with an internal API so flamboyantly baroque that frankly we can't even comprehend where to begin," Zawinski wrote.

He was being sarcastic, but that's pretty much true. And ... it's true of Konqueror too.

Open Source is, in general, lousy. I have read a dozen good articles on why, which I can't put my fingers on at the moment.

Open Source has its place. Its place is NOT on the desktop of anyone who wants to get things done.

Many people do not want to get things done. For these people, Open Source is wonderful.

But since you can't even INSTALL A PROGRAM in Linux without running 100 esoteric commands, don't start telling me that it has ANY impact on sales of Windows.

I wanna install MySQL for Windows? I download the file, double-click, and wait... good, installed.

Wanna run it? It's in the start menu.

Now, want to install MySQL for Linux? Let's see:

- Download it.
- tar -xvf it.
- Configure.
- Make
- Make Install
- Realize that it tried to install itself in a DIFFERENT place from the default MySQL (non-functional in the case of Red Hat, partly functional in the case of Mandrake) that came with the distro.
- Cancel, swear.
- Make clean.
- Configure (again)
- Edit config file by hand because automatic configurer doesn't do what you want.
- Make
- Make Install
- Edit MySQL config files
- RUn it a few times from the command line...
- Slap self, realize that although it shipped with 3 executables, only one of them will run, and it's the "safe mode" one.
- Check documentation... yeah, only mysqld_safe_mode actually works.
- Sigh in frustration.
- Fire it up, set up a root password.
- Realize you've just locked yourself out of the database.
- Read errata. Discover that thousands of others made the same mistake... there's even a way to undo it!
- Make DB_Unlock
- Run it again. This time, cutting and pasting from the documentation. Good, now you have a user named Larry who has system access... but "root" does not. Oh well, you can live with Larry.

But this is PROGRESS? MySQL is the ****ING PINNACLE of opensource development, but on the FLAGSHIP OPERATING SYSTEM for which it was DESIGNED FROM THE BEGINNING, it takes 3 hours and a year off my life to set it up?

And don't even ****ING tell me I don't have the "skills". You can't honestly ****ING say that you didn't take JUST as long to set it up the first time you installed it. I know, because all the Linux gurus I know chuckle when I tell this story, and nod their heads because they KNOW.

------------------

Now, is Linux and Open Source good for servers? Sure.

Just not on ANY SYSTEM WHERE WORK MUST BE DONE.

And don't say it'll be ready any time now. Since 1992, I've been hearing that Linux is almost ready for prime time. That "next year" people will be using it on the desktop. That's 12 years. In all that time, it has NEVER made serious desktop inroads.

And it won't any time soon. At least not until people STANDARDIZE. Which, sadly, is the OPPOSITE of open source. Oops.

- Gurm

[cjolley]

You go GURM.
chuck

[dZeus]

Originally posted by Gurm
<cut>
Now, want to install MySQL for Linux? Let's see:

- Download it.
- tar -xvf it.
- Configure.
- Make
- Make Install
- Realize that it tried to install itself in a DIFFERENT place from the default MySQL (non-functional in the case of Red Hat, partly functional in the case of Mandrake) that came with the distro.
- Cancel, swear.
- Make clean.
- Configure (again)
- Edit config file by hand because automatic configurer doesn't do what you want.
- Make
- Make Install
- Edit MySQL config files
- RUn it a few times from the command line...
- Slap self, realize that although it shipped with 3 executables, only one of them will run, and it's the "safe mode" one.
- Check documentation... yeah, only mysqld_safe_mode actually works.
- Sigh in frustration.
- Fire it up, set up a root password.
- Realize you've just locked yourself out of the database.
- Read errata. Discover that thousands of others made the same mistake... there's even a way to undo it!
- Make DB_Unlock
- Run it again. This time, cutting and pasting from the documentation. Good, now you have a user named Larry who has system access... but "root" does not. Oh well, you can live with Larry.

- Gurm [/B]

but all of that is covered in the 150 page manual... jeez, how can people be so lazy? It only takes 3 years of your life to read the pages, now stop whining

[dbdg]

Only ever installed MySQL and PHP on a 2k machine, never realised what a pain it was for the 'alternate' OS.