I think the people who refer to the terminal as "leaving the development environment" are missing the point; bringing up a terminal requires me to press exactly one key, and pressing it again gets rid of it. Do you IDE proponents really think that the ability to do just about anything from a scriptable popup window with history and other bells and whistles is ancient/useless/outdated/whatever?

Of course, an IDE that also exported all its functionality as command line utilities would be even better; there's no arguing that a refactoring IDE is an essential tool when working with verbose, enterprisey languages like Java and C#.

Quote: Original post by mikeman
AMD and nvidia are irrelevant hardware vendors when it comes to desktop computers? Is that what you're saying? Because I lost track of your argument right there. How are they irrelevant when most desktops have AMD or nvidia chips in the graphics card, used for anything from video decoding to 2D or 3D graphics? Are you talking about Intel's Larabee taking over? Cloud computing, OnLive-like terminals? I have no idea.

Regardless, you can't have your cake and eat it too, I think. Yes, MS does break its driver compatibility, but it also accepts closed source drivers from graphics vendors, and they accept Microsoft's. On the linux "ecosystem", things are so liquid, at least that's how it seemed to me. They won't stabilize the internal API so that AMD/Nvidia can target drivers to their system(Nvidia has proven OpenGL-friendly; that's why it was easier for that department, AMD not so much; what are you going to do about it), but demand open-source drivers, so when any change in the kernel happens, they can fix it themselves. Which is all fine and dandy, except the vendors don't want to do it, because cutting-edge 3D graphics in time for the latest AAA megahit game brings them nice big fat $$$. So, what now? Merge AMD and NVidia so the competition vanishes?

In a nutshell, I'm at loss at what you guys propose the linux people should do to gain significant share in the desktop world. I'm also at a loss at what exactly do they mean when they say 'linux taking over the desktop world'. Let's define those? What do they mean? That, regardless of what people have to use in the office when they work, in their homes they'll have linux-based OSes installed, and this effect will slowly work its way towards the top and take over the corp world as well? What are the solutions? Just "get rid" of all the "naysayers" or have them "join"? That's it? Let's here some positive solutions then?

On corporate desktops AMD and nvidia are irrelevant, Intel is dominating that segment unless you look at high end workstations. and as i said, ignore the damn kernel, its irrelevant, all enterprise Linux based Operating Systems have a stable kernel API, If you want to release proprietary drivers for RHEL6 thats not a problem, go for it, its kernel API won't change and its no different than releasing drivers for Windows7 , they might work with RHEL7/Win8 but you shouldn't assume that they will.

Basically all the bitching about the kernel API not being stable is nonsense because within a given OS version it is always stable (With the only exception being bleeding edge or amateur distributions, but running those in a production enviroment is rather silly in the first place)

The problem is basically that some people take a group of 500+ Operating systems developed during the last 20 years and then for some insane reason expect a single version of their driver to work on all of them, and when it doesn't they bitch about the kernel API not being stable, the fact that a single driver can work on multiple operating systems from different vendors is impressive, You won't see OS X and Windows sharing drivers, yet SLES and RHEL happily does most of the time despite being different Operating Systems (Expecting them to always be able to share drivers is wrong, they are different Operating Systems and should be treated as such, and yes it means that the marketshare for each OS is even smaller).

Quote: Original post by SimonForsman
The problem is basically that some people take a group of 500+ Operating systems developed during the last 20 years and then for some insane reason expect a single version of their driver to work on all of them, and when it doesn't they bitch about the kernel API not being stable, the fact that a single driver can work on multiple operating systems from different vendors is impressive, You won't see OS X and Windows sharing drivers, yet SLES and RHEL happily does most of the time despite being different Operating Systems (Expecting them to always be able to share drivers is wrong, they are different Operating Systems and should be treated as such, and yes it means that the marketshare for each OS is even smaller).

Great. You found that insane reason at the end of your own obnoxiously long sentence. Indeed, usually people expect a certain amount of flexibility as for what machine to run their program on. Only rarely do people code and use a program all on the same machine. What is bizzare is expecting people to write drivers for the tiny sliver of market share each linux distro occupies, stable or not.

Quote: Original post by Eelco

Quote: Original post by SimonForsman
The problem is basically that some people take a group of 500+ Operating systems developed during the last 20 years and then for some insane reason expect a single version of their driver to work on all of them, and when it doesn't they bitch about the kernel API not being stable, the fact that a single driver can work on multiple operating systems from different vendors is impressive, You won't see OS X and Windows sharing drivers, yet SLES and RHEL happily does most of the time despite being different Operating Systems (Expecting them to always be able to share drivers is wrong, they are different Operating Systems and should be treated as such, and yes it means that the marketshare for each OS is even smaller).

Great. You found that insane reason at the end of your own obnoxiously long sentence. Indeed, usually people expect a certain amount of flexibility as for what machine to run their program on. Only rarely do people code and use a program all on the same machine. What is bizzare is expecting people to write drivers for the tiny sliver of market share each linux distro occupies, stable or not.

What are these mythical problems with the proprietary drivers anyway? As long as you're not running a bleeding edge kernel, which nobody is - or should be - doing, they work just as well as they would on Windows. That they're slower and get features later than their Windows isn't because of any alleged API woes, but because it's written first and foremost for Windows, and the Windows version gets a lot more manpower.

Quote: Original post by Eelco
What is bizzare is expecting people to write drivers for the tiny sliver of market share each linux distro occupies, stable or not.

Thats the point though, it is a misconception that Linux users want or expect that, we don't, that is why we prefer opensource drivers (Because thats the only way to support such a large number of operating systems with such a small userbase properly), proprietary drivers work but maintaining them is extremely expensive (There is a reason most hardware vendors have gone opensource for their Linux drivers, and that reason isn't that it makes them feel good about themselves).

Complaining about a lack of drivers/software/services/whatever is natural and necessary, people who shut up and stay quiet doesn't exist(in the eyes of the vendors) and people who doesn't exist will not have any products manufactured for them.

I vote with my wallet, i always ask about Linux support before buying a product, having the store personel check it up for me means that:
1) I don't have to do it myself
2) They will know that it is a consideration for some customer.

(I did the same when i bought my last laptop, i asked specifically for one that had Linux pre-installed or had certified hardware (I ended up getting one with Windows that was certified for SLED9 which was good enough). (Unfortunatly it had an AMD graphics card so i can't actually use a newer distribution since AMD dropped the card to legacy support just a few months after my purchase)

If a vendor doesn't want my money thats fine, but i do use my right to let them know what they need to do to get it. (For hardware its basically opensource drivers or a damn good trackrecord of keeping the proprietary drivers updated, if my perfectly working and reasonably new hardware turns into a paperweight because i update my OS (be it Windows, Linux, whatever) that manufacturer won't get anymore of my money until they've proven that the next item i buy will be better supported.

Quote: Original post by Valderman
What are these mythical problems with the proprietary drivers anyway? As long as you're not running a bleeding edge kernel, which nobody is - or should be - doing, they work just as well as they would on Windows.

It might look like that from the surface, but there are much deeper issues with proprietary drivers under Linux.

The most obvious one are the very volatile ABIs. Breaking changes are made on a constant basis, sometimes without any logical reason beyond the ego-trip of some high-ranked project maintainer / contributor. All that is less of a problem if you have the driver source, but it makes maintaining closed source drivers very annoying. If a hardware manufacturer (who is obviously profit-oriented) decides to support Linux, he either has to accept the idiotic political agenda of RMS & co and open source their drivers (which is often legally impossible), or he is at the whim of kernel/X/whatever developers who decide to change the API because they just feel like it that day. Both scenarios are unacceptable.

But this is not the worst part. Let me introduce the FOSS version of a DRM that leaves basically all commercial (and much criticized) DRM systems in the dust when it comes to restrictiveness: GPL_ONLY kernel interfaces. So you're writing a closed source driver module that is interacting with the kernel. Yet, you cannot just use any technically available kernel interface. Because many are labeled as GPL only. Means that if you link to these interfaces, your closed source driver suddenly becomes a derivative work of the kernel. Great.

But we aren't done yet. Lately, efforts are under way to remove old, non-GPL interfaces from the kernel and replace them by GPL-only interfaces. There are no technical reasons for this. It's only about political agenda. They're essentially replacing these interfaces to lock out non-GPL drivers. This in turn means that on a kernel update you'd not only have to put up with breaking API/ABI changes, but you could suddenly face a situation where a kernel interface that is vital to your driver becomes legally unavailable to you. And that means rewriting and duplicating the functionality of these interfaces by yourself, from scratch. Welcome to the wonderful world of free™ software.

And in the case of NVidia, let's not forget why they are maintaining a Linux driver. Not because of desktop Linux users or consumers (which make less than 1% of their global driver download, from what I remember). They're doing it for corporate clients using Linux on large scale industrial visualization workstations, and who indirectly pay for the Linux driver through the overpriced Quadro FX product line.

In conclusion, and at least in my opinion, the main problem of Linux is not really of technical nature. All the problems about package management, window manager and whatnot can be solved. What cannot be solved is the fact that some individuals are using Linux as the vehicle for their own political agendas. Linux is the only mainstream OS that almost forces a developer to accept a retarded political manifest before usage.

Imagine Microsoft stating in their EULA that you may only use the Platform SDK if you submit proof that you voted Republican...

Quote: Original post by Yann L

But this is not the worst part. Let me introduce the FOSS version of a DRM that leaves basically all commercial (and much criticized) DRM systems in the dust when it comes to restrictiveness: GPL_ONLY kernel interfaces.

Ah, the paranoid ramblings of a delusional lunatic.

How many GPL-only kernel APIs are there?

Zero. Zip. Nada. Bupkiss. Not a sausage. Goose egg. Bugger-all. Nil. Zilch.

What chance is there that Linus would accept such APIs? Zero. You are more likely to win the jackpot on your local megalottery 3 times in a row. Linus is not interested in foaming-at-the-mouth free software zealots or what they would like to do to his kernel.

How many of the prominent kernel developers (almost all of whom are employed by large publicly-traded companies who are profit-driven) would be working on something like that? I dunno. Your guess.

How many of the vast majority of Linux distributions would accept such a thing? Not many, considering they're mostly hardware manufacturers (public traded companies) or profit-driven distros (profit-driven companies), and all of them could toss the Linux kernel very quickly and pick up something unencumbered, like one of the BSDs. Your phone/video player/GPS/router doesn't have to run Linux, it's just easier for the OEMs because of the wide knowledge and experience base for driver writers.

There are some distros that do not accept software under a license that is not compatible with the GPL, except for maybe the Linux kernel (which, btw, is not compatible with the GPLv3, to the frustration of the FSF). Good for them, they are free to do as they please. This is not true of most Linux distros you're likely to encounter outside of geekdom.

Like I said in a previous post, there are zealous fanboyim in every OS camp. Sometimes the foam in your mouth sprays into your eyes and blinds you.

Quote: Original post by Yann L

Quote: Original post by Valderman
What are these mythical problems with the proprietary drivers anyway? As long as you're not running a bleeding edge kernel, which nobody is - or should be - doing, they work just as well as they would on Windows.

And in the case of NVidia, let's not forget why they are maintaining a Linux driver. Not because of desktop Linux users or consumers (which make less than 1% of their global driver download, from what I remember). They're doing it for corporate clients using Linux on large scale industrial visualization workstations, and who indirectly pay for the Linux driver through the overpriced Quadro FX product line.

My point exactly. And the funny thing is, just like my original post, it's because I want to set up my own personal render farm. anyway, i have my own reason on own vs paid render farm. in my pipeline, there's a place for both.

Quote: Original post by mikeman
In a nutshell, I'm at loss at what you guys propose the linux people should do to gain significant share in the desktop world. I'm also at a loss at what exactly do they mean when they say 'linux taking over the desktop world'. Let's define those? What do they mean? That, regardless of what people have to use in the office when they work, in their homes they'll have linux-based OSes installed, and this effect will slowly work its way towards the top and take over the corp world as well? What are the solutions? Just "get rid" of all the "naysayers" or have them "join"? That's it? Let's here some positive solutions then?

The "year of Linux on the desktop" ride is over. It's not going to happen.

You can't name a technical feature that would promote widespread acceptance of Linux on the desktop because there isn't one. All three of the common desktops solutions (Mac, Windows, Linux) are techinically indistinguishable, and all are good enough for yer typical user.

The one simple, positive solution for Linux to be accepted as a desktop alternative is for major hardware makers to offer it as an alternative through their channels into the retail sector. It's just that simple.

Only its not that simple. A few years ago, and OEM called Asus came up with a small cheap computer that became colloquially known as a "netbook." It ran Linux only because Microsoft demanded more in licensing fees per unit than the machine was selling for, and because the only consumer operating system Microsoft was willing to license (dubbed 'Vista') required more resources than were available on the hardware. Asus chose to have a custom Linux distro created in a matter of a few months, and for a while you could pick up an Eee PC in a retail store and it ran Linux. Sames were amazing, outselling regular PCs in some (very important) markets.

First thing that happened is Microsoft took their XP operating system out of mothballs, because it could run on that hardware if you removed a bunch of stuff, and licensed it at a loss to netbook manufacturers.

Second, the channels stopped moving Linux-based netbooks in the US. It was not clear why, but it seems there were 'incentives' involved.

Finally, the CEO of Asus stood in front of a very nice ARM-based netbook at a trade show (the netbook had excellent HD multimedia playback and a very fast boot time and a very exciting touchscreen interface, thanks, send job offers by PM) and declared that Asus was not a Linux company and would henceforth ship only Microsoft Windows.

What happened was Microsft told Asus that if they pulled a stunt like that again, they would get no Microsoft licenses every again. A familiar refrain.

But, times move on. You can now buy select Dell computers with Ubuntu instead of Windows, and shortly certain other big-name manufacturers will offer the same option. Only the channels remain to be conquered, and then you will be able to walk into a Best Buy and walk out the same day with a computer that has Ubuntu preinstalled. That will be the arrival of Linux as a generally recognized desktop system.

As soon as you can buy Ubuntu preloaded on a computer at Wal-Mart or Best Buy, you will see the few game studios that sill target PCs make games for Linux.

Quote: Original post by Bregma
How many GPL-only kernel APIs are there?

On my current kernel, 2.6.22, over 560 symbols are exported as GPL-only.

Amongst them, the entire lowlevel USB subsystem, the ATA and SCSI subsystems, ACPI, I2C bus, IEEE1394, part of the PCI and video subsystems, and many more.

Quote: Original post by Bregma
What chance is there that Linus would accept such APIs? Zero. You are more likely to win the jackpot on your local megalottery 3 times in a row.

Yeah, right:

Quote:
A controversial patch for the imminent kernel 2.6.25 is causing much debate in the developer community: in a similar move to one he made two years ago, the well-known kernel developer Greg Kroah-Hartman has submitted a patch that prevents closed source USB drivers from using the kernel's USB driver API.

Kroah-Hartman's patch has already been accepted by Linus Torvalds, and it will be part of the Git tree for the next version of Linux. It prevents closed source USB drivers from addressing the kernel's USB interface.

Quote: Original post by Bregma
How many of the prominent kernel developers (almost all of whom are employed by large publicly-traded companies who are profit-driven) would be working on something like that? I dunno. Your guess.

Dum dee dum....

Which then leads to 'fun' little things like that one. Just a random poor guy I found on Google. Many more exist. I specifically like the absolutely unbiased reply by Greg Kroah-Hartman:

Quote:
> -EXPORT_SYMBOL_GPL(put_device);
> +EXPORT_SYMBOL(put_device);
No, sorry, I've already successfully taken legal action against
companies who have tried to go around the driver core's GPL-only
symbols, so I can not, and will not, make this change.
thanks,
greg k-h

Quote: Original post by Bregma
How many of the vast majority of Linux distributions would accept such a thing?

Every single one of them using kernel 2.4+.

Quote: Original post by Bregma
Sometimes the foam in your mouth sprays into your eyes and blinds you.

I fully agree... *cough* *cough*