Having one system in which your current clipboard is accessed by ctrl+c/x/v AND highlight/middle-click which a simple docked util to let you choose between... lets say 10 clipboards is a far superior system.
Having two seperate systems, where every other OS in existance supports both a single functionality is the broken part. The only advantage again is multiple clipboards and there are better ways to handle it which require only one system that functions in a fashion that is familiar to everyone on earth who is familiar with copy/paste.
Our laws of physics, particularly when your talking about something non-terrestrial are bit too shaky to assume anything based on what we expect to see and don't, wouldn't you say?
As far as speed... well I haven't benched it, but it's not particularly dog slow... I copy files of whatever size and don't get annoyed.
Read support has been stable for ages, although NTFS support is not generally compiled into any main distro kernel by default.
As for write support, at first it ate filesystems and completely corrupted them. Then they made a util to fix them... maybe. Then it got better. Then it got much better (in the meantime everyone has been ranting about lousy ntfs write support in linux). I started using it in the early to mid 2.4 series kernels and haven't had any issues... period, I've never had to touch a special utility to fix screwed up NTFS write support.
As of 2.6 NTFS write support is no longer marked experimental in the kernel config. I guess that means they've finally declared it stable.
Linux can both read and write NTFS. Read support has been stable for eternity now, write support was finally marked stable in the 2.6 kernel.
I've been using NTFS write support for the past several versions.
I don't know if people assume NTFS doesn't work on linux because distro's don't generally include it in their kernel builds or because the write support was horrid and corrupted filesystems once upon a time.
Yeah but the poster does need to look again. NTFS write support is no longer marked as experimental in the 2.6 kernel, and it's actually worked quite well for some time before that.
But write support is no longer marked experimental in the 2.6 kernel.
For good reason I'd say, I've been using NTFS write support for the past several revisions without a single hiccup.
First I was cautious and ginger in my handling of NTFS writes, and then more bold. Now I don't consider corruption anymore than I would with windows. I guess that comes from hundreds if not thousands of writes without a single issue *shrugs*.
In any case, if the kernel maintainers think it's safe to take off the experimental tag, and I've used it without any problems. Maybe it'll go well for you too.
NTFS write used to be horrid, and required external cleanup utils just to use. That's long long gone, if you've been afraid to touch it because of being burned in the past, seriously, it's time to try again.
""Explain to me again what the benefits of NOT having a graphical installer are again?"
You don't have to worry whether the video card is properly supported by the installer. You can install on a headless server via serial port. Many distros (and FreeBSD) use the same application for initial installation and post-installation configuration. You wouldn't be able to ssh in to change something later. A non-GUI installer is faster. A non-GUI installer is simpler and therefore less likely to break."
Okay, lots of nice arguments for having a text based installer. Unfortunately that's not the question I asked. You do realized we don't have to have one or the other right... we CAN have both and some distributions already do.
""But EVERY application should also have both a text mode and Gui installer. This installer should default to options for the most ignorant who want to "next next next finish" through an install and have moderate and advanced mode options (moderate allowing the user to choose things like static locations, various sensible configuration overrides."
No, every application should require exactly one mouse click or shell command to install. For example, a FreeBSD user can install one of over 10,000 third-party software packages just by going to a particular directory in the filesystem and typing "make install clean". The OS downloads, patches, compiles, and installs the software. If the software had any compile-time options, the OS sets them for you. And it just works, unlike the rpm/apt/yum trainwreck that most Linux distros these days are reduced to. Installation is just copying files onto the hard disk. No binary package should ever have to come with its own installer."
Actually apt/yum at least are pretty smooth layers on top of rpm. There really is no trainwreck to speak of... but it is all on the repository, not the tool, just like BSD;)
I couldn't disagree with the one click install theory more. I disagree with it in Mac OS, I disagree with it in apt/yum and I disagree with it in BSD.
That's like a bad wizard gone REALLY damn bad. Instead of not presenting enough options for advanced users, it presents NO options to ANY users. Even your most primitive user understands the options for putting a shortcut in the menu and/or desktop. What I'm aiming for is virtually any level of user installing the app and being finished, without ever needing to configure beyond the options in the installer. At least 90% of the time.
Installation means copying the files to the drive, creating links as appropriate, installing all needed libraries, and putting the application into a fully usable and configured state. Perhaps setup is a better word for what I'm talking about.
"What you really want is a graphical front-end to the package management systems that exist today. Unfortunately, a decent one doesn't yet exist."
If that's what I was after synaptic would be perfect if it were bundled with apt and rpm. It's not as I'm sure my previous statement made clear.
"Yes, and the authors do this wherever they can. They certainly don't want to waste their time writing code that already exists and Linus doesn't accept patches that are too similar to existing code. But the fact is that two different ethernet cards, even if they do the same thing and have the exact same features, can have an entirely different architecture and therefore require entirely different driver code. Writing one module to support them both would be far uglier than writing two modules that support them individually, for a number of obvious reasons. There's something to be said for NVIDIA's unified driver architecture, but there are significant drawbacks as well. If ethernet drivers came packaged like this, Linux would be useless for low-end hardware like 486's and first-generation Pentiums. (Which I do indeed still use for various tasks.)"
Right, and this is different from what I said how exactly? I wasn't proposing grouping mod
Late 90's early 00's. I rest my case. Tell me about the fonts overhaul they did last week or last month and then we'll be talking about a project moving at open source speed.
I'm going to have to withdraw my small concession that jargon file may have been correct at one point.
It seems that the jargon was NOT correct to begin with and the current Jargon file states as much:
"BASIC stands for "Beginner's All-purpose Symbolic Instruction Code". Earlier versions of this entry claiming this was a later backronym were incorrect."
Maybe you missed Microsoft losing market share for the first time... period.
Maybe you missed that 97% of the desktop market shrink to 93%.
I sure didn't. And since apple's market share is staying about the same, not signficantly increasing, where exactly is it you think that market share went?
Rather odd that all Dartmouth resources (including those written by the authors of the language) say it's an acronym for Beginner's All-purpose Symbolic Instruction Code.
So whether the jargon file is correct or not, The authors have blessed the acronym repeatedly and therefore it is correct. What used to be true is irrevelent, after being blessed by the originals authors the acronym is fact and to say BASIC does NOT stand for Beginners all-purpose symbolic instruction code now is incorrect.
All resources from Dartmouth and the authors of the language also make clear that it was intended as a beginners language for learning and a stepping stone to REAL languages like FORTRAN and C.
"Noun 1. thief - a criminal who takes property belonging to someone else with the intention of keeping it or selling it"
Not only is your definition wrong, but even using your definition a copyright infringer is not a thief.
You do know copyright'd works are not owned by the copyright holder don't you? They actually aren't even ownable.
Works which qualify for copyright are unownable or owned by all mankind whichever way you want to look at it. Copyright is a temporary grant of limited privilages to the first person who thought the idea.
It's impossible to steal someone's copyright, and therefore impossible for a copyright infringer to be a theif.
Losing a civil suit is not a "conviction" of any sort.
By definition, anything which subjects you to a lawsuit is NOT a criminal action and whether you win or lose you are NOT a criminal.
Copyright infringment doesn't make your a thief or a criminal anymore than someone painting your house and falling off a ladder does. They are about equivelent offenses (assuming your mass duplicating and selling).
"It should be obvious that creating and maintaining those wonders of mad science can't be easy for them and they would prefer to work toward a future when the important patches go into the mainline kernel."
Should be, but download the SRPM for the FC2 kernel. I'm too lazy to go back in and count, but there are ALOT of patches.
"No it doesn't. It downloads the source to a thin shim that interfaces the binary blob with one of a select set of kernel/XFree86 combinations. When new versions appear you get to wait for them decide the new version is important enough to bother supporting."
That has only happened once thus far and that's with the 2.6 kernel which completely broke compatibility with EVERY driver open and otherwise. You'll see in the Nvidia forum where I bitched and continue to rant on them about this one. This is different, this is NOT in the mainline kernel, Nvidia doesn't have a responsibility to make their driver work with the unstable version of a popular distribution.
"Wrong. The fastest supported 3D card in the Free Software world is the Radeon 9200. Anything newer requires binary drivers and is therefore outside the scope of the Free Software or even Open Source movements. If you, as someone outside of these closely allied movements, manage to get a binary driver working, great for you. Free Software is for everyone, even thouse who disagree with the goals of the developers. You can power a puppy masher with Debian and not violate the license but you should not expect anyone else to abandon the goals of the FS/OSS movement to help keep it running for you. Same for Nvidia support. It just isn't on our radar and you should be bright enough to figure that out."
I run several GPL'd projects on sourceforge and code for a few more. Please don't try to tell me about the goals of the developers or who is and isn't a member of the community. That's not for you to judge.
I'd love to see a world in which all the drivers were open source, but I think it's ignorant and foolish to expect that to actually become a reality or to ignore what is out there. After all, using a binary driver is NOT supporting them with your dollars.
In the case of the kernel, Linus is making the right choice and can certainly expect the kernel to bend to his calls. In the case of a single distro it needs to bend to the needs of that distro's users. 70% of the Users is a hell of need and better be on the radar binary or otherwise.
"The 4K stack thing appears to be pretty important to solving some serious scalability issues and appears destined for the mainline 2.6 kernel. Which is probably why RH slipstreamed it into FC2, to get the 'issues' hammered out before shipping it in RHEL4."
This is a pretty significant issue wouldn't you say? I'd agree it helps with some scalablity issues, what does that have to do with the home audience that Fedora primarily supports again?
"Anyway, Fedora Core is developed in the open. Nvidia has know about the situation for months, so why isn't the lack of an updated driver their problem?"
Fedora core is one distro, not even the most popular, not even the most popular in the US. Nvidia announced long ago they'd be working on the 4k thing. Fedora chose not to wait, despite the fact that it breaks most of their users, despite the fact that they could have patched it into an update kernel down the road, and despite the fact that it doesn't significantly benefit most of their users.
Nvidia will likely have support in time before it's introduced in the stable kernel, which is where their target SHOULD be. RHEL might be able to get away with this, unlike fedora THAT is the number 1 distro in the US at least. Fedora is NOT redhat, they do NOT have the muscle to push 3rd parties to do what they want.
Oh come on now, admit you got a chuckle out of my example of what's theoretically possible;)
This is one my pet peeves, I don't think we do nearly enough questioning of what we generally think of as fact in physics.
Black holes are good example, they teach that they are collapsed stars as fact in grade and high school. They teach alot of these theories (that aren't even truely theories, merely hypothesis) as fact.
I haven't looked that vanilla 2.6.5 and I'm not sure if it made it in. But kernel preemption is certainly in the Fedora 2.6.5 kernel, it's just turned off.
The fedora/redhat kernels have always been anything but stock, usually includes 20 patches or so that aren't in the vanilla kernel... So I'm afraid I'm really not following you on this.
"As for the Nvidia drivers, so what?"
How about their the fastest cards on the market and include the best linux support of any high performance video card out there. As a result something like 90% of linux desktops are running Nvidia cards. Not being ok with Nvidia is one thing, making a decision without significant benefit that breaks 70% of your overall userbase (no my numbers don't conflict, not EVERYONE running fedora is a desktop user) is a piss poor decision.
"Once you admit you are a second class citizen who accepted a list of Linux kernel/XFree86 versions approved by Nvidia you can STFU and leave the rest of us in peace and go camp on the Nvidia website awaiting their permission to upgrade to new versions."
I'm not sure WTF your talking about here. There are precompiled modules but the nvidia installer downloads the source and compiles the module on the spot to work with whatever version of X and Kernel you are using.
Kernel 2.6.5, or 2.6.6 did NOT break the nvidia drivers at all. FEDORA broke the drivers with a patch FEDORA put in. The stock kernel and every other distro's version of it works just fine.
Disclaimer: I love Linux, I love open source. They are beautiful concepts, they are beautiful ideas. I setup Linux systems everywhere I can and use Linux myself. I've setup experienced users, new users, servers, etc. I've written open source applications. Believe me, I'm not an anti-Linux guy in any sense.
Disclaimer2: Insert disclaimer 1 again here. Some of the suggestions and things I'm going to mention are implemented in windows. I do NOT want Linux to be just like windows. Simply because some features are in windows which make it more user friendly isn't a knock on linux... which has numerous features that make it superior to windows. There are areas in which windows is ahead of the game, mostly because of the outlook I'm trying to throw off with this disclaimer. These are good ideas and implemented in some fashion in most gui's not just windows. They aren't windows behavior, they are features we are missing and ignoring out of stubbornness, lets fix it.
Disclaimer3: There are exceptions to everything. There are apps already which have portions or some of the ideas I'm laying on the table in them already.
1. Distro Installers
There are still distributions without Graphical installers and without hardware detection. Now there are plenty of reasons for having good text or curses based installers. Explain to me again what the benefits of NOT having a graphical installer are again?
There are a lot of poor hardware detection implementations out there, and we've all been burned by them. But I believe the open source community is powerful enough that bad implementations will either be dropped or fixed to the point that they are good implementations.
So explain to me again what the disadvantages are of a good hardware detection system that allows manual overrides in every instance but doesn't require them are again?
1. Application Installers
The same that is true for distros is also true for all applications. I hear you all crying this or that package management frameworks solves this problem. NO it doesn't. Package management is a great and useful piece of the puzzle.
But EVERY application should also have both a text mode and Gui installer. This installer should default to options for the most ignorant who want to "next next next finish" through an install and have moderate and advanced mode options (moderate allowing the user to choose things like static locations, various sensible configuration overrides. Advanced allowing setting of things like buffer settings, number of child processes, anything to do with pipes, and settings only developers and programmers will make sense of).
Personally I see the need for a general scriptable toolkit for making these installers that should be out there from the start. It would check to make sure there are packages for all the major distributions available as well as a source package. User downloads the installer, installer downloads the appropriate package for their distro. The installer gives an option of Internet or local directory containing the install files or this can be preset in the installer script.
Basically I mean an install shield wizard type of thing that auto detects if running from he cli or gui and is 100% statically linked for it's own libs.
Some type of central application for removing programs is also needed, this can just read the list from the package manager if needed but should have a simple wizard type uninstall.
Wizards are not the root of all evil, crappy wizards that don't allow flexibility are the root of all evil. It's an important distinction. I believe wizards are good idea that is generally poorly implemented. Neglecting one class and knowledge level of user or another.
3. Hardware detection after install.
That's right, your not done with hardware detection after the base install. Most distro's neglect this. For a lot of things which are automatically setup they act as if a system is static and doesn't change.
Mandrake 10 was officially released about two days ago? FC2 was released a week and half ago... I'm not sure where you get your perception of time, but it's a bit confused.
Slashdot Mirror
The broken part is that they are two systems.
Having one system in which your current clipboard is accessed by ctrl+c/x/v AND highlight/middle-click which a simple docked util to let you choose between... lets say 10 clipboards is a far superior system.
Having two seperate systems, where every other OS in existance supports both a single functionality is the broken part. The only advantage again is multiple clipboards and there are better ways to handle it which require only one system that functions in a fashion that is familiar to everyone on earth who is familiar with copy/paste.
Our laws of physics, particularly when your talking about something non-terrestrial are bit too shaky to assume anything based on what we expect to see and don't, wouldn't you say?
If they are being sued for such relatively small sums, particularly for unpaid rent, it's highly doubtful the rumors are off by much.
Just a brush with NTFS in linux.
As far as speed... well I haven't benched it, but it's not particularly dog slow... I copy files of whatever size and don't get annoyed.
Read support has been stable for ages, although NTFS support is not generally compiled into any main distro kernel by default.
As for write support, at first it ate filesystems and completely corrupted them. Then they made a util to fix them... maybe. Then it got better. Then it got much better (in the meantime everyone has been ranting about lousy ntfs write support in linux). I started using it in the early to mid 2.4 series kernels and haven't had any issues... period, I've never had to touch a special utility to fix screwed up NTFS write support.
As of 2.6 NTFS write support is no longer marked experimental in the kernel config. I guess that means they've finally declared it stable.
Linux can both read and write NTFS. Read support has been stable for eternity now, write support was finally marked stable in the 2.6 kernel.
I've been using NTFS write support for the past several versions.
I don't know if people assume NTFS doesn't work on linux because distro's don't generally include it in their kernel builds or because the write support was horrid and corrupted filesystems once upon a time.
Yeah but the poster does need to look again. NTFS write support is no longer marked as experimental in the 2.6 kernel, and it's actually worked quite well for some time before that.
But write support is no longer marked experimental in the 2.6 kernel.
For good reason I'd say, I've been using NTFS write support for the past several revisions without a single hiccup.
First I was cautious and ginger in my handling of NTFS writes, and then more bold. Now I don't consider corruption anymore than I would with windows. I guess that comes from hundreds if not thousands of writes without a single issue *shrugs*.
In any case, if the kernel maintainers think it's safe to take off the experimental tag, and I've used it without any problems. Maybe it'll go well for you too.
NTFS write used to be horrid, and required external cleanup utils just to use. That's long long gone, if you've been afraid to touch it because of being burned in the past, seriously, it's time to try again.
""Explain to me again what the benefits of NOT having a graphical installer are again?"
;)
You don't have to worry whether the video card is properly supported by the installer.
You can install on a headless server via serial port.
Many distros (and FreeBSD) use the same application for initial installation and post-installation configuration. You wouldn't be able to ssh in to change something later.
A non-GUI installer is faster.
A non-GUI installer is simpler and therefore less likely to break."
Okay, lots of nice arguments for having a text based installer. Unfortunately that's not the question I asked. You do realized we don't have to have one or the other right... we CAN have both and some distributions already do.
""But EVERY application should also have both a text mode and Gui installer. This installer should default to options for the most ignorant who want to "next next next finish" through an install and have moderate and advanced mode options (moderate allowing the user to choose things like static locations, various sensible configuration overrides."
No, every application should require exactly one mouse click or shell command to install. For example, a FreeBSD user can install one of over 10,000 third-party software packages just by going to a particular directory in the filesystem and typing "make install clean". The OS downloads, patches, compiles, and installs the software. If the software had any compile-time options, the OS sets them for you. And it just works, unlike the rpm/apt/yum trainwreck that most Linux distros these days are reduced to. Installation is just copying files onto the hard disk. No binary package should ever have to come with its own installer."
Actually apt/yum at least are pretty smooth layers on top of rpm. There really is no trainwreck to speak of... but it is all on the repository, not the tool, just like BSD
I couldn't disagree with the one click install theory more. I disagree with it in Mac OS, I disagree with it in apt/yum and I disagree with it in BSD.
That's like a bad wizard gone REALLY damn bad. Instead of not presenting enough options for advanced users, it presents NO options to ANY users. Even your most primitive user understands the options for putting a shortcut in the menu and/or desktop. What I'm aiming for is virtually any level of user installing the app and being finished, without ever needing to configure beyond the options in the installer. At least 90% of the time.
Installation means copying the files to the drive, creating links as appropriate, installing all needed libraries, and putting the application into a fully usable and configured state. Perhaps setup is a better word for what I'm talking about.
"What you really want is a graphical front-end to the package management systems that exist today. Unfortunately, a decent one doesn't yet exist."
If that's what I was after synaptic would be perfect if it were bundled with apt and rpm. It's not as I'm sure my previous statement made clear.
"Yes, and the authors do this wherever they can. They certainly don't want to waste their time writing code that already exists and Linus doesn't accept patches that are too similar to existing code. But the fact is that two different ethernet cards, even if they do the same thing and have the exact same features, can have an entirely different architecture and therefore require entirely different driver code. Writing one module to support them both would be far uglier than writing two modules that support them individually, for a number of obvious reasons. There's something to be said for NVIDIA's unified driver architecture, but there are significant drawbacks as well. If ethernet drivers came packaged like this, Linux would be useless for low-end hardware like 486's and first-generation Pentiums. (Which I do indeed still use for various tasks.)"
Right, and this is different from what I said how exactly? I wasn't proposing grouping mod
Late 90's early 00's. I rest my case. Tell me about the fonts overhaul they did last week or last month and then we'll be talking about a project moving at open source speed.
I'm going to have to withdraw my small concession that jargon file may have been correct at one point.
It seems that the jargon was NOT correct to begin with and the current Jargon file states as much:
"BASIC stands for "Beginner's All-purpose Symbolic Instruction Code". Earlier versions of this entry claiming this was a later backronym were incorrect."
Anyone who tries to claim that XFree86 development hasn't been damn near stagnant for the past several years is on something.
Put in the hands of a proper OPEN development system X will move MUCH faster than it did with the previous maintainers.
It's slowly but surely crushing it like a bug.
Maybe you missed Microsoft losing market share for the first time... period.
Maybe you missed that 97% of the desktop market shrink to 93%.
I sure didn't. And since apple's market share is staying about the same, not signficantly increasing, where exactly is it you think that market share went?
The sun? The hell with that, go with the easier answer, blast it toward somewhere elses sun ;)
;)
Or cheapest yet, just jet it to our moon.
It's not like these capsules are coming back, or we have to monitor them. Once off our planet it doesn't really matter where they go.
And if a good dose lands on the E.T. home planet, well too bad, worse case we get to meet them sooner
That's great and all, but we haven't put that money toward renewable sources. And as such we have to work with what we DO have NOW.
Rather odd that all Dartmouth resources (including those written by the authors of the language) say it's an acronym for Beginner's All-purpose Symbolic Instruction Code.
So whether the jargon file is correct or not, The authors have blessed the acronym repeatedly and therefore it is correct. What used to be true is irrevelent, after being blessed by the originals authors the acronym is fact and to say BASIC does NOT stand for Beginners all-purpose symbolic instruction code now is incorrect.
All resources from Dartmouth and the authors of the language also make clear that it was intended as a beginners language for learning and a stepping stone to REAL languages like FORTRAN and C.
You can build EVERY function and control structure which exists in procedural programming in ASM.
Which is why all the first compilers are written in it and alot of them merely translate the code into assembler.
If you want to learn about how the computer works, there is no better choice than assembler.
Beginners All-purpose Symbolic Instruction Code was also designed to teach people how to program.
"Noun 1. thief - a criminal who takes property belonging to someone else with the intention of keeping it or selling it"
Not only is your definition wrong, but even using your definition a copyright infringer is not a thief.
You do know copyright'd works are not owned by the copyright holder don't you? They actually aren't even ownable.
Works which qualify for copyright are unownable or owned by all mankind whichever way you want to look at it. Copyright is a temporary grant of limited privilages to the first person who thought the idea.
It's impossible to steal someone's copyright, and therefore impossible for a copyright infringer to be a theif.
Losing a civil suit is not a "conviction" of any sort.
By definition, anything which subjects you to a lawsuit is NOT a criminal action and whether you win or lose you are NOT a criminal.
Copyright infringment doesn't make your a thief or a criminal anymore than someone painting your house and falling off a ladder does. They are about equivelent offenses (assuming your mass duplicating and selling).
"It should be obvious that creating and maintaining those wonders of mad science can't be easy for them and they would prefer to work toward a future when the important patches go into the mainline kernel."
Should be, but download the SRPM for the FC2 kernel. I'm too lazy to go back in and count, but there are ALOT of patches.
"No it doesn't. It downloads the source to a thin shim that interfaces the binary blob with one of a select set of kernel/XFree86 combinations. When new versions appear you get to wait for them decide the new version is important enough to bother supporting."
That has only happened once thus far and that's with the 2.6 kernel which completely broke compatibility with EVERY driver open and otherwise. You'll see in the Nvidia forum where I bitched and continue to rant on them about this one. This is different, this is NOT in the mainline kernel, Nvidia doesn't have a responsibility to make their driver work with the unstable version of a popular distribution.
"Wrong. The fastest supported 3D card in the Free Software world is the Radeon 9200. Anything newer requires binary drivers and is therefore outside the scope of the Free Software or even Open Source movements. If you, as someone outside of these closely allied movements, manage to get a binary driver working, great for you. Free Software is for everyone, even thouse who disagree with the goals of the developers. You can power a puppy masher with Debian and not violate the license but you should not expect anyone else to abandon the goals of the FS/OSS movement to help keep it running for you. Same for Nvidia support. It just isn't on our radar and you should be bright enough to figure that out."
I run several GPL'd projects on sourceforge and code for a few more. Please don't try to tell me about the goals of the developers or who is and isn't a member of the community. That's not for you to judge.
I'd love to see a world in which all the drivers were open source, but I think it's ignorant and foolish to expect that to actually become a reality or to ignore what is out there. After all, using a binary driver is NOT supporting them with your dollars.
In the case of the kernel, Linus is making the right choice and can certainly expect the kernel to bend to his calls. In the case of a single distro it needs to bend to the needs of that distro's users. 70% of the Users is a hell of need and better be on the radar binary or otherwise.
"The 4K stack thing appears to be pretty important to solving some serious scalability issues and appears destined for the mainline 2.6 kernel. Which is probably why RH slipstreamed it into FC2, to get the 'issues' hammered out before shipping it in RHEL4."
This is a pretty significant issue wouldn't you say? I'd agree it helps with some scalablity issues, what does that have to do with the home audience that Fedora primarily supports again?
"Anyway, Fedora Core is developed in the open. Nvidia has know about the situation for months, so why isn't the lack of an updated driver their problem?"
Fedora core is one distro, not even the most popular, not even the most popular in the US. Nvidia announced long ago they'd be working on the 4k thing. Fedora chose not to wait, despite the fact that it breaks most of their users, despite the fact that they could have patched it into an update kernel down the road, and despite the fact that it doesn't significantly benefit most of their users.
Nvidia will likely have support in time before it's introduced in the stable kernel, which is where their target SHOULD be. RHEL might be able to get away with this, unlike fedora THAT is the number 1 distro in the US at least. Fedora is NOT redhat, they do NOT have the muscle to push 3rd parties to do what they want.
I know I know, but I didn't write it that way to begin with and am too lazy to add the markup after the fact.
;P
Next time I'll do the markup, your really right on that one. Geez, I got mixed up on item number 1, that's pretty bad
Oh come on now, admit you got a chuckle out of my example of what's theoretically possible ;)
This is one my pet peeves, I don't think we do nearly enough questioning of what we generally think of as fact in physics.
Black holes are good example, they teach that they are collapsed stars as fact in grade and high school. They teach alot of these theories (that aren't even truely theories, merely hypothesis) as fact.
I CAN fix it with a recompile?
I haven't looked that vanilla 2.6.5 and I'm not sure if it made it in. But kernel preemption is certainly in the Fedora 2.6.5 kernel, it's just turned off.
The fedora/redhat kernels have always been anything but stock, usually includes 20 patches or so that aren't in the vanilla kernel... So I'm afraid I'm really not following you on this.
"As for the Nvidia drivers, so what?"
How about their the fastest cards on the market and include the best linux support of any high performance video card out there. As a result something like 90% of linux desktops are running Nvidia cards. Not being ok with Nvidia is one thing, making a decision without significant benefit that breaks 70% of your overall userbase (no my numbers don't conflict, not EVERYONE running fedora is a desktop user) is a piss poor decision.
"Once you admit you are a second class citizen who accepted a list of Linux kernel/XFree86 versions approved by Nvidia you can STFU and leave the rest of us in peace and go camp on the Nvidia website awaiting their permission to upgrade to new versions."
I'm not sure WTF your talking about here. There are precompiled modules but the nvidia installer downloads the source and compiles the module on the spot to work with whatever version of X and Kernel you are using.
Kernel 2.6.5, or 2.6.6 did NOT break the nvidia drivers at all. FEDORA broke the drivers with a patch FEDORA put in. The stock kernel and every other distro's version of it works just fine.
Disclaimer: I love Linux, I love open source. They are beautiful concepts, they are beautiful ideas. I setup Linux systems everywhere I can and use Linux myself. I've setup experienced users, new users, servers, etc. I've written open source applications. Believe me, I'm not an anti-Linux guy in any sense.
Disclaimer2: Insert disclaimer 1 again here. Some of the suggestions and things I'm going to mention are implemented in windows. I do NOT want Linux to be just like windows. Simply because some features are in windows which make it more user friendly isn't a knock on linux... which has numerous features that make it superior to windows. There are areas in which windows is ahead of the game, mostly because of the outlook I'm trying to throw off with this disclaimer. These are good ideas and implemented in some fashion in most gui's not just windows. They aren't windows behavior, they are features we are missing and ignoring out of stubbornness, lets fix it.
Disclaimer3: There are exceptions to everything. There are apps already which have portions or some of the ideas I'm laying on the table in them already.
1. Distro Installers
There are still distributions without Graphical installers and without hardware detection. Now there are plenty of reasons for having good text or curses based installers. Explain to me again what the benefits of NOT having a graphical installer are again?
There are a lot of poor hardware detection implementations out there, and we've all been burned by them. But I believe the open source community is powerful enough that bad implementations will either be dropped or fixed to the point that they are good implementations.
So explain to me again what the disadvantages are of a good hardware detection system that allows manual overrides in every instance but doesn't require them are again?
1. Application Installers
The same that is true for distros is also true for all applications. I hear you all crying this or that package management frameworks solves this problem. NO it doesn't. Package management is a great and useful piece of the puzzle.
But EVERY application should also have both a text mode and Gui installer. This installer should default to options for the most ignorant who want to "next next next finish" through an install and have moderate and advanced mode options (moderate allowing the user to choose things like static locations, various sensible configuration overrides. Advanced allowing setting of things like buffer settings, number of child processes, anything to do with pipes, and settings only developers and programmers will make sense of).
Personally I see the need for a general scriptable toolkit for making these installers that should be out there from the start. It would check to make sure there are packages for all the major distributions available as well as a source package. User downloads the installer, installer downloads the appropriate package for their distro. The installer gives an option of Internet or local directory containing the install files or this can be preset in the installer script.
Basically I mean an install shield wizard type of thing that auto detects if running from he cli or gui and is 100% statically linked for it's own libs.
Some type of central application for removing programs is also needed, this can just read the list from the package manager if needed but should have a simple wizard type uninstall.
Wizards are not the root of all evil, crappy wizards that don't allow flexibility are the root of all evil. It's an important distinction. I believe wizards are good idea that is generally poorly implemented. Neglecting one class and knowledge level of user or another.
3. Hardware detection after install.
That's right, your not done with hardware detection after the base install. Most distro's neglect this. For a lot of things which are automatically setup they act as if a system is static and doesn't change.
Mandrake 10 was officially released about two days ago? FC2 was released a week and half ago... I'm not sure where you get your perception of time, but it's a bit confused.