This screams "I have altered the deal, pray I do not alter it further"
and would now even consider buying one of their mobile devices if it came with a keyboard.
"But what use is a phone if you cannot.. speak" - the iPhone as a phone is absolutely shithouse, no tactile feedback like with buttons, and the pda like functionality leaves a lot to be desired, nice replacement mp3 player though
The tech unsavvy as you say are not getting any advantage out of this, what the hell do they care what something was written in so long as it functions well and serves the purpose the customer wants.
Feeding the control freaks by buying their products is an interesting thing to do, but I question whether you've thought of the larger implications.
it's fantastic; develop apps in a way apple can control, continuing to make the phone relatively bug free and easy to support
s60 has had an open model for years before the iPhone, and I use plenty of quality apps even without a central store running quality tests on it, let alone severely limiting developer freedom like apple has in the name of 'quality'. Limiting choices does not equate to better quality, time, effort and caring do.
305MB needed to install k3b, 234MB for Amarok, and an additional 60-80 packages...
And after you installed k3b, you would find that the 234mb figure for amarok would be down to like 20mb max (just because amarok is large). By your logic with that you should include gtk+ with every gtk app you use, similar sizes would ensue. Many many apps use qt, not just a few. That you've chosen to limit yourself to gtk apps effects how many of them you know, and you only need to get QT etc once. Just like you only need to get GTK once
If it were a gigantic library that were only used for one program I could see your hesitance, however your argument seems to be, 'it wasn't in the default install on my system, so I don't want it'. Then again, most sane distributions include kde and QT with the default install with gnome and avoid that large download you mentioned anyway.
If you fail to see that 234MB of dependencies to just use a simple music player seems silly then I dont think there is a lot more I can contribute to this thread.
Every high end gui app has heaps of dependencies. To think it doesn't is ludicrous, do an ldd on gedit a simple text editor and look at all of that. To a person without gtk, you'd be looking at a similar size of libraries just for a mere text editor, do I count the text editor as being that large, no, I concede that the library is useful for other things it may enable me to run, and install it, then suddenly everything works.
The solution is for everyone to have both sets of libraries, more or less. If my current machine from 2002 (don't game so didn't see the point in upgrading) can handle it I'm guessing yours can sacrifice the 300mb of storage and a hundred or so mb of ram to run any program you find useful.
They don't want both vast sets of libraries eating up all their resources. Either Gnome or KDE is a resource pig, running a good chunk of the libraries of both is a nightmare.
I'm doing so on a machine made in 2002 as my main machine (don't game so don't see the point in upgrading) And I see no issue. Most people I know upgrade their machines a lot more frequently and place usability and functionality over 'oh noes, 100mb more ram in use'.
From what the proponents of gtk only systems say, you'd think that using qt takes up gigs of ram, it doesn't.
I fail to see why so many people using gnome hate anything that uses QT/kde libraries with such a passion. By doing so you are seriously limiting yourself and overlooking some nice software.
Amarok, k3b, k9copy (only decent dvd ripper I've found on linux suitable for recommending to others), konqueror (meh as a web browser but great for viewing local filesystem and sftp'ing with other machines, like a swiss army knife), kino for converting dv cam footage. etc.
The recent trend over the last few years for everyone to default to gnome and nobody having used any qt stuff seems strange to me, I always have both sets of libraries installed and use the best tool for the job.
and now have an HP 50G calculator running off 4 AA batteries with a faster ARM CPU. I do appreciate the architecture and power efficiency of ARM designs.
Are hp still emulating the saturn processor on their arm devices? while I understand with that model they are aiming for backwards compatibility. Attaching an arm clocked at 75mhz to a measly 512kb of ram and a 131x80 pixel screen seems ridiculous.
I know it's just a calculator and there to get the job done, but native code is nice and quick and using less cpu power lets the batteries last longer.
The TI nspire seems to be the only graphic calculator out there with a modern design.
How does the DRM affect you? It's merely there to enable/ you to play DRM'd files. It doesn't restrict you with anything. But if you have such files, it allows you to play them. How is that worse than Linux where you can't play them at all?
First off, drm is flawed since the content to be displayed has to be shown to the same person you're trying to obfuscate it from somehow
How does this related to linux? for the DRM to be effective you would have to stop people modifying the kernel since then they could just strip things of drm and write the resulting output to disk.. bam, drm removal done.
So either drm is supported in a way that lets you effectively completely remove drm (most people wouldn't mind this) or they try to completely lock you out of tinkering with your own system in the name of protecting the drm. That is what people have issue with.
and my guess is that if you've done any at all, its been to the open source world where its expected that someone somewhere will have to hunt down all the dependencies that you so flagrantly didnt bother to include.
Well having your programs in the main repository IS a major advantage to code re-use, having everyone link to common code with clear cut dependencies that are automagically handled is convenient
Shipping naked executables with none of its dependencies is amateur and unrealistic, so in the real world dynamic linking does not reduce the number of bytes needing to be distributed, that quite the contrary it increases the number of bytes needed.
Depends on the method of distribution, to argue that the linux yum/apt way of installing software is wasteful with dynamic libraries is a very hard argument to defend. Windows has crap all commonly distributed useful libraries so it's all statically linked because each author thinks "bah, what user of my software would already have it installed" thusly it never gets installed, repeat.
Even in a far from ideal windows environment, there is nothing stopping your installer from checking at install time if dependencies are there, if they are at least the required version, and if not launching another installer for the library. Yes The distribution of bytes would be larger but the actual installed size would be smaller due to it only ever being installed once.
Remember when directx was new and launchers would offer to install directx? similar but with libraries and more auto-detection
You offering up scenarios where it makes sense to dynamic link, but completely ignoring all the cases where it makes no sense at all.
If you read the post above my initial one, I was responding to this:
Bottom line: dynamic libraries are, in nearly all cases, just a horrible mistake that history has yet to correct.
Considering the way the linux software ecosystem works, it's hard to say that it's horrible for all cases yes? considering dynamic linking is the default way to do things for efficiency and it all just works.
Of course I'll grant you that for extremely obscure 'no-one is really going to need this' libraries, on windows. Static linking could be quite preferable. Especially when the libraries are proprietary and not meant for reuse.
The problem under discussion is that the decision to static link is much worse than it should be, even much worse than it used to be.. that static linking has gone downhill into bloatedness for no good reason other than lazy library organization and poorly written linkers.
I stepped in when I heard someone pipe up saying dynamic linking sucked for nearly all situations, for windows machines perhaps but far from it in linux/bsd/etc.
Given the number of functions in a library like libc and the number of programs likely to need each of them at any given time, that is probably the least convincing argument ever made for using dynamic libraries.
Every process you run is using a shared library of some description usually quite a few of them, use ldd to figure it out yourself.
Your argument basically comes down to every single program should completely reinvent the wheel by including the code to do absolutely everything itself, that, is insane.
Yes you wouldn't be writing it yourself, but you are distributing hundreds of the exact same library, in a place (in binary) where it cannot be updated
Moreover, other than for near-universal functionality like libc or your basic OS integration stuff, how many libraries are really used by several different programs at the same time anyway?
at what artbitrary point do you stop calling it 'os integration stuff' when it all comes stock with most distros, I mean arguably qt and gtk are libraries separate to the 'os' same with SDL, crystalspace etc, then you go onto specific function support like libacl, libpthread, sockets, etc all of which are libraries on top of the kernel and with every linux distro.
Library re-use is everywhere in the linux world, to think it isn't is insane.
Next up, we have performance, or rather lack of it, since you can't globally optimise over code linked to a standard library the way you can to code linked statically.
So... you are really going to 'optimize' things from a completely foreign codebase that you have had no prior experience to on the source tree... to try and 'improve' performance on a single part for your needs?
You would be better off writing the needed functionality yourself from scratch in that instance, and we all know how well that goes.
Bottom line: dynamic libraries are, in nearly all cases, just a horrible mistake that history has yet to correct.
I for one, do not want the gigantic mess that is having everything statically compiled. From a deployment perspective on a system that likely won't have installed libraries, it's useful, but the real solution is to.. install the libraries.
you really want every single QT app including it's own version of QT? fine, add 30mb or so to every single app that uses it's gui, same deal with gtk.
Here's a real life program example where dynamic libraries solved a problem. Neverwinter nights, had a linux release, it used SDL for the interface and loaded the library dynamically.
If it were static, the new outputs for sound output in SDL would not be available, but since it was dynamic, the new version can be used and huzzah we have jack and pulseaudio support.
On top of that, many applications wind up depending on subtly different versions of dynamic libraries,
This, is why there's a different.so extension for each time they break the api (if it's a well thought out api this should only happen once in a blue moon) This api compatibility through the symbol tables are how dynamic libraries work, and why they work so well.
#hello world tiny program .equ SYSCALL, 0x80 .equ SYS_EXIT, 1 .equ SYS_WRITE, 4 .equ STDOUT, 1
.section.data hello: .ascii "hello world!\n"
.section.text
.globl _start _start: movb $SYS_WRITE, %al #put write syscall in eax movb $STDOUT, %bl #set stream to stdout movl $hello, %ecx #give address of start of buffer to print movb $13, %dl #how many characters of buffer to print int $SYSCALL movb $SYS_EXIT, %al int $SYSCALL
The above is a tiny hello world program i wrote myself, it's worth noting that even the resulting binary is larger than it needs to be, I wound up with a 133 byte binary by moving the text string into the ELF header via hex editor, and changing the instruction data to point to the new addresses.
Kind of hard to get it smaller than that while keeping it in ELF format, considering the actual object code in the binary was something like 15 bytes with the data illegally in the header.
Crimes, or committing 'offences' are defined by law, law and morality often conflict, not to mention it is practically impossible for any given person to know all laws
According to law, ignorance of the law is not an excuse for breaking it, while morals vary between the person there tends to be common understood standards for most things in a society. I would argue that if a law is unknown to you, and you do something that a majority of your peers would consider moral, if not legal, it should be justification.
Even upon knowing the law and willingly breaking it it can be justified, in some places it's illegal to copy government documents on the local laws due to 'copyright' could you honestly argue that it is immoral to break that copyright in order to share the information with the people who are beholden to those laws?
There comes a point where laws must be broken, granted copying movies isn't that point (for me, and most people), but to say there is no moral right to do any crime is a hard sell, when any given action can be described as a crime by the state.
The only tough Apple products to work on nowadays are some of the ipods. (the "ipod classic" comes immediately to mind)
And the ipod touch, etc, not sure about you but I get a craptonne more ipod service requests than actual mac computer ones, I agree mac pro's aren't difficult to service but compare how many people have mac pros compared to ipods, etc.
As for "1mm screws", that's almost funny to read.
See ipod touch for that one
Where are you pulling your arseformation out of anyway?
From a friend who has been an apple service provider for about fifteen years, and disassembly of imacs/ipods etc myself.
You must be new to apple service. I've been at it for going on 10 years. I'll take a new mac to work on any day over an old one. 40+ screws of 15 different sizes in random places to replace the logic board in a clamshell ibook from '98 is a great example.
Oh I already know how bitchingly difficult some of the old g3's etc could be, just because their main product line is a lot easier than it used to be doesn't mean it's not ridiculous compared to other modern machines.
Putty knife with the mac mini anyone?
To be fair my hatred of apples methods of keeping people out probably stems from the sheer amount of ipod classics and touches I have to fix compared to other apple hardware, fact is those are their most popular products though.
Today I do warranty repair work for Apple at an AASP.
Dear god you must enjoy pain, as newer apple products come out they continue to progress towards 'no user servicable parts' with more and more annoying ways to keep people out of them (1mm phillips screws etc etc)
As a tinkerer/fixer of things it must be frustrating to work with such hostile hardware.
How does a stable ABI product drivers, I'll tell you how, by making it trivial for the companies to support you!
This involves some very large assumptions, you are assuming it is extremely difficult to get stable tested drivers into mainline, and you are assuming that having a stable ABI will somehow make life easier. They still have to release source anyway, so why not get it into mainline? at which point having a stable abi means nothing.
Newsflash: even with a stable ABI some vendors *gasp* won't release linux drivers, and even if a perfect OSS driver is made, the vendor could still not say it works on linux in the packaging
You seem to hate the very idea of drivers being in the kernel at all. Also seeming to lack understanding of how drivers work in the linux kernel, they go by chipset not by device id thusly a single driver can support hundreds of devices that are practically identical except for the company that made them. Each vendor wouldn't have to release a driver like they do with windows, only the chipset manufacturer would (and they do, why do you think 95% of common hardware is supported out of the box on linux) and once devices are released with the chipset their device ID is added to the driver saying if this hardware appears, use this driver.
This results in the benefit that if the vendor of your hardware goes out of business quickly, or just ditches you, you aren't stuck, drivers are still actively maintained, as opposed to possibly getting stuck with crappy drivers that could bring down the system.
Most common devices conform to specifications, i.e. webcams conforming to USB video and the like, thus work straight up.
In the end having drivers in kernel stops all of the fucking around you have to do on other systems like windows.
while Linux zealots argue whether they should allow binary blobs or not they are about to get train fucked and don't even know it! How, you may ask? by a little piece of MSFT engineering known as ExFAT [wikipedia.org] that's how? It is patented up the ass, which means no more free shit, and all the flash based devices will be switched over in about 3 years. hell even the last 8Gb drive I picked up at Big Lots had ExFAT and a driver CD. See, there is that pesky "drivers on CDs" thing again.
The only notable advantage of exFat over fat32 is the larger than 4gig single file support, and by formatting it as that you essentially kill all current forms of portable device support, fat32 will still live for quite some time to come because of all the embedded support. Portable hard disks already use ntfs which linux can use. And there has been an open source read only driver for linux for exfat since the beggining of 2009 with write forthcoming, haven't encountered any devices that use it yet myself. To think this is a show-stopper is extremely naive.
Regardless, it is apparent that you really don't care how things work, why they work, or have any real clue as to why things are the way they are (hint: it's not because everyone happy and using linux are 'linux elitists')
You expect everything to work the way that windows and to a much lesser extent mac os x do, and the fact is linux is a very different design and what works for them would not work for linux.
Again you completely ignore every single thing I wrote.
It was read in entirety, but as said I only commented on the parts relevant to the scope of the argument (stable ABI) You are the one that keeps trying to up the scope to the whole "linux is not ready for the desktop" business. I have no interest in changing scope or changing what is being discussed. Perhaps it is my fault for responding to some of the off topic parts.
And funny you should mention FSF, which of course is headed up by RMS, the most left wing radical zealot on the face of the planet. do you know what "PC" he runs? I do, it is a Loongson Netbook, because it is the ONLY machine on the entire planet that will meet his radical idea of "free", why do you people still take advice from that nut?
What makes you think I take advice from him? All I said was a likely course of action from the FSF if something came to pass, which you have to admit given their stances they would likely do. Throughout this conversation you always assume much in certain ways when I have given you little reason to do so.
I already pointed out your putting kernel numbers, which would be like expecting Windows users to know which kernel and patch level their PC was up to, is a complete waste of time, because by the time the device hits market it will already be far out of date.
Here's a thought, say your stable ABI is implemented, you put a linux sticker on, now someone sees this and tries to install it on their ancient 2.6.13 linux install (obviously with no abi support) it has the linux sticker doesn't it? the driver on the disc should work shouldn't it? even in your scenario, a version number would be required.
Also, you mostly missed the point with that especially judging by your "because by the time the device hits market it will already be far out of date." the idea would be to put the kernel version the driver went to mainline in, so you don't need that particular version, that or anything newer would function just fine.
And yes, with vendor support hardware is added to mainline kernel all the time BEFORE the hardware is even released, so when packaging is being made you could know what the minimum version is etc
So I am curious to hear your non ABI solution.
See above, the hardware would show it supported linux and how recent the version has to be for it to work seamlessly.
This would require nothing from the part of developers, all that is needed is a logo and the version number put on the box to hardware that has support. Ironically I have found hardware with such details already, but in the extreme minority. For it to happen the vendor has to have an interest in caring enough to even recognize linux support when it's been made by others etc, so you'll never have logos on all the equipment supported, but you would be guaranteed the items that did worked for that version and later.
Now for the side-track questions..
Now here is a question for you? How much time did you waste researching products before purchase? 5 hours? 6?
I never research before buying, when it comes to motherboard/cpu/videocard/sound... and yes, I haven't had a single piece of software not work for a base computer, could say I'm lucky, but I've went through five very different machines all to the same effect.
And when was the last time you fired up bash...hmmm? Last month? Last week? Today?
I always have four or five terminals open, mostly because I don't close windows for weeks, and that my work is faster with it than a gui, sure I could do without it, but why limit myself and make my day to day activities slower and harder?
such as the Linux user that told me with a straight face I should force Joe and Sally average to "embrace the power!" of CLI. damn, that still cracks me up.
what, you gonna end up shipping on 14 DVDs? You DO know that the number of devices continues to go UP and not down, right?
The entirely of the linux kernel with full support for 20 years worth of equipment comes to 30mb... I have seen single windows drivers that were over 100mb in size, while that was inefficient even a well written windows driver would be somewhat larger than the linux one, because linux driver components reuse themselves, and makes driver writing that much simpler.
Have to write a driver for a new wifi card? the 80211 stack is already there, basically everything is, all you would have to write is device specific things like telling the existing infrastructure how the memory map of the device works, and where the registers and buffers are etc.
Somewhat better than reinventing the wheel with every driver, yes?
Again, most of your post is irrelevant to the topic in discussion, but I'll respond to the relevant parts
I notice you didn't link to the discussion, and I know why,because I have already read it.
Actually it was because I was time constrained and on a device with limited bandwidth (phone) some people do work at work.. sometimes:) don't jump to conclusions
While not exactly the thread I was meaning, this (notably c.2.2) contains part of what I meant.
Still am rather short on time, but the gist of it was more or less a stable ABI greatly limits what the kernel developers can do, i.e. if the most efficient way to do something breaks it, or they need to implement extra functionality that would break it, they can't. Linus doesn't want his hands tied
On a tangent to the link I mentioned (well.. slightly related I guess) is the following Any device driver that was written specifically for linux is by default under the GPL license when distributed, while linus wouldn't enforce this on things he does not consider derived works, you can bet your ass the FSF would if linux specific binary blobs became common, so even with a stable ABI, source would have to be provided anyway.
This isn't really a problem because vendors who do write linux drivers tend to provide source anyway.. that gets into mainline in time. If they have to release source anyway (in 99% of cases) why have a limiting stable ABI?
"Linux is free if your time is worthless"
Silly question, how long does it take you to install office, visual studio 2008, photoshop (or gimp, or whatever) a bittorrent client, a decent cd burning program.. the list goes on. Windows is FAR from complete out of the box, and it doesn't even have a nice repository like system to install things, overall install time is ridiculous to get a functional system for people that actually want to do things besides ms paint.
You still say the linux kernel devs are just 'elitist' because they won't pander to what you want even though what you want results in a poor engineering decision.
the argument for a stable ABI came up in 1993 or so, feel free to check the lkml archives on the topic, there are reasons for why things are the way they are now. This is not a dictatorship, sound technical decisions take precedence over almost all else.You may see this as 'elitist' but it's more just pragmatism.
Of course the irony of it all is that linux has the widest range of hardware support of basically any os out of the box because of the way it's designed
It is actually quite simple, having a stble ABI would mean that device manufacturers could write once, use for years, as they currently enjoy with Windows and OSX
This also means users have to hunt down said driver, install it, and also that it will at some point be completely useless when that particular ABI is thrown out, a few years down the track.
with Linux I have to give up control to some guy and pray he doesn't fuck me or spend crazy money constantly cranking out new drivers.
You know that in house company drivers are accepted into the linux kernel yes? the only requirements are related to code style (not a problem if you've aimed to get it included from the start, which you should be if you are writing a linux driver) and quality. While people are free to make their own versions etc you can be paying the maintainer and he could be an employee.
Same deal as windows more or less except your source code is open, and you have a couple of restraints in regard to style, but ending in something much more useful
Now before you say "What if Windows comes out with a new version 6 years from now"? Well I don't care, because by then my device will long be off the shelves and I don't support dumpster divers.
You may like forced obsolescence and everything only being short term, but I for one do not. (one of my main boxes was made in 2002, still running latest linux etc just fine) people don't like it when their hardware becomes unsupported for no good reason besides 'buy new stuff'.
But then we get to Linux. to support Linux first of all I can't do the logical thing, which is write a driver and put in on the CD,
This is only logical to windows users, ideally you should never have to install drivers. In the days of yore everything was running out of the box albeit with rather fixed systems.
followed by MSFT releasing a nearly decade old WinXP onto the lanscape, which promptly completely slaughtered.
People like what is familiar, people also like playing games, this is the same reason mac machine sales greatly increased after it became possibly to easily install windows on them, this is not unique to linux
All hardware vendors have a vested interest in making the software that runs on their hardware cheap, because it enables people to buy more hardware. End users buy very little comparatively to HPC because they don't need it and/or don't have the money. It's a simple thing of how much more hardware will we sell if we support the extra os, for anything high end like cad users, hpc, this is high, low end for there to be incentive you need large numbers of the small orders, which as you say linux does not yet have.
where we will prove Linux at retail is a giant clusterfuck!
This is not the point I disagreed with you with, you should be arguing how a stable ABI will fix the driver situation, which you so clearly stated earlier it magically would. Which is what I disagreed about. There is a myriad of problems with selling linux to average consumers in non-appliance form of course.
The fact is, having a stable ABI would create more problems than it solves, and fails to solve what you wanted resolve anyway (better/more drivers).
No go to the "big three" Walmart.com, staples.com, and Bestbuy.com, and place these three things in your cart, remember NO research! Place a USB wifi stick, a USB TV Tuner, and a USB all in one printer.
Printers I'll give you, never bought a random one because I like true postscript printers that aren't exactly consumer goods. But I buy random usb wifi sticks with no research all the time, and either I'm just lucky or they all work these days, I only started doing that in 2006 or so so prior to that it probably was a clusterfuck. TV tuners can't say I have any usb ones but I have a cheap ass chinese pci one that I don't even know the brand of that works here, which ironically I can't even get to work on windows (on the version it was designed for too). But can't say that's consistent because I don't go out and buy tv tuner cards all the time etc.
But ironically, although i've answered your question, all of the above is moot, because you have still failed to address how having a stable ABI would somehow make drivers magically appear. Your initial argument was that having a stable ABI
And you mention Nvidia? Can I laugh now? Do you have any idea how much $$$ Nvidia spends having to constantly update their drivers just so they'll continue working?
You do realize that the base of the nvidia linux drivers are essentially the same as the windows driver.. right? Yes they spend a bit of money on linux specific interfaces like vdpau, but that's hardly the kernels 'fault' they are putting new functionality in their drivers yes?
Linux guys will still scream "Next year is the year of Linux on the desktop!"
The 'year of the linux desktop' imho is not so much a single year where everyone uptakes linux, but rather like a curve, different people have different needs etc, and every year linux fulfils a slightly larger subset of those needs. Linux adoption will be gradual, and generally only by those who care enough to even look into it.
In a decade OSX will be around 10%
Now that IS a very bold claim, for every five people I see with a macbook on average only one of them is running OS X, they may achieve that much in hardware sales in the future, but actual people running os x? bold prediction
And as a retailer I just think it is a damned shame, but I'm not gonna go bankrupt trying to support your OS when you can't even get a stupid penguin put on the boxes at walmart.
And nobody ever asked you to, if it doesn't make business sense don't do it. If you re-read my posts my only gripe with your posting is the belief having a stable ABI is some kind of magic bullet to fix the problems at retail, it really isn't and even if you somehow had full hardware compatibility with linux(and a stable ABI would not do that), you would still have higher return rates etc and other problems.
heh, I don't have the time to waste with people like you, continue to believe as you wish, but the fact you said
Your "things won't change!" argument. Well no shit.
And you still wanting to implement a failed strategy is quite telling
Your arguments are full of elitism and full of fail. Watch as I blow them completely out of the water.
Cocky one aren't we much? considering your post has little to no real content
1.-Having the kernel devs do it-Total fail, because your kernel devs should be...oh I don't know....actually working on the KERNEL instead of playing driver fixit boy,
Have you LOOKED at the kernel source or changelogs any time lately? Drivers are by far the majority of the kernel, and it's by far most of what is worked on. By most accounts the linux kernel is a fair way to 'done' with most companies and users being happy with the non-driver feature set with there being little else to add besides driver support.
Most of the new items always will be drivers, because the quality improvements of being in mainline are real, and even you would have to agree attaching a piece of hardware and having it just work is better than actually having to install anything.
This animosity to BETTER driver support seems strange to me, considering you were bitching about it.
If I am a manufacturer, I can write just 4 drivers, that's right, just 4 drivers, and cover Windows for a decade and a half...2K/XP32, XPx64/2K3x64, Vista/7,Vista/7x64. See?
how many manufacturers do this, especially if a new windows version comes out say, two or three years after the hardware is released, answer: fuck all. The hardware is then useless to those who aren't willing to have a separate machine to run the old os. Same with xp supported hardware these days, it's going the way of the dodo, everything wants vista and up because no drivers are written for xp any more.
Linux, on the other hand, is a complete and total clusterfuck where I have to either give all my code to some guy and hope like hell he gets off his ass quick enough to get the driver into mainline before my device is no longer sold, and any driver I release my self on the CD with Windows and OSX will in all likelihood NOT WORK by the time it hits the shelves.
Ever used the nvidia binary blob installer? it's quite possibly to have a small open source compatibility layer that functions for *gasp* many different kernels, inefficient way to do it, but if you _need_ closed source, it has been done before while maintaining compatibility with newer versions
And don't forget we are talking a year to 2 years before a device goes from designed to on your shelves, and the average Ubuntu is how long again? Six months? See the problem here?
Not in the slightest, if anything it's a good thing because it gives you plenty of time to make a driver that works, sane drivers once written will continue to work, amazingly every driver isn't rewritten every kernel version, to do so would be ludicrous. Your insistence on a stable ABI while making life easier in the short term would architecturally compromise things in the kernel.
Sorry but the entire Linux method ATM is nothing but a fail whale.
Well, you may say it's 'linux elitism' but the way things work currently works for millions of (mostly technically literate, but increasing number not) users, we depend on the quality control of the mainline devs a lot, if a company isn't willing to write drivers that work with multiple kernel versions (just a compile away with the right abstractions) why should we trust the quality of such a shoddy product in the first place?
So much for 'blowing my argument out of the water' the almost childish use of language at times combined with not actually addressing any of the points I raised does not an argument make.
European powers (England at the time, but there was also France and Spain)
France bankrupted itself supporting the colonists against the british, spending only 20% less than the british did themselves in the endeavour. (in the realm of a hundred million pounds in 1700's money) Which prompted the events of bastille day.
A lot of sheer luck enabled the US to become independent, England has other fish to fry and a lot of disadvantages in regards to long communication times, having to leave troops in captured territory so that the revolutionaries wouldn't just return, etc
Again with the stable ABI argument, we've had this discussion before (hmm should maybe pay slashdot so I can access my full posting history *sigh*) and I thought I managed to get you to concede that even having a stable ABI would not solve a thing.
stable ABI so the driver they write a year ago when the device was made will work now,
If the driver is in mainline, when they plug it in it will just 'magically' work, better than windows or os x on many fronts
With very few exceptions (nvidia mostly) if they aren't willing to write an open source driver for linux, they aren't willing to write a closed source one either.
By having a stable ABI you are forcing kernel developers to wind up making unnecessary compatibility layers to the 'real' functions when they inevitably change at some arbitrary point in the future. You limit exposure of future kernel functions, and everyone winds up reinventing the wheel.
To add insult to injury, you would lack the quality control of the mainline kernel and wind up with a situation similar to windows in which bad drivers bring down the system.
So while the ABI proposal fails at it's main purpose (getting more linux drivers) it also from a technical viewpoint adds unnecessary complexity to an already complex system with no benefit.
Still agree with your branding proposal though otherwise, only everything with the linux branding would have to be in mainline when released, with minimum kernel version listed on box, thus they wouldn't even have to ship drivers on cd, the hardware would be guaranteed to 'just work'
So far as the return rates, The majority of people that would just purchase a pc would not know what linux is to start with, and likely didn't know what they were getting into. Those that do probably want to install your own flavours so selecting supported hardware is more the service they'd pay for.
The young (children) and the elderly who don't play games are the best candidates for linux, but they aren't the ones who buy the most computers.
Ironically, one of the biggest strengths of linux is that when hardware does work, it continues to work, MFM hard drives were only just discontinued in mainline, even though said hardware is basically from the 80's
I dare you to attempt to get a printer from 1998 working on windows 7, it will make any linux troubles you have had look like childsplay.
In summary, you seem to be willing to throw the baby out with the bath water thinking a stable ABI will be a magic solution, if it were truly beneficial it would have already happened, the negatives are too great and the perceived benefits are simply not there.
Slashdot Mirror
This screams "I have altered the deal, pray I do not alter it further"
and would now even consider buying one of their mobile devices if it came with a keyboard.
"But what use is a phone if you cannot.. speak" - the iPhone as a phone is absolutely shithouse, no tactile feedback like with buttons, and the pda like functionality leaves a lot to be desired, nice replacement mp3 player though
The tech unsavvy as you say are not getting any advantage out of this, what the hell do they care what something was written in so long as it functions well and serves the purpose the customer wants.
Feeding the control freaks by buying their products is an interesting thing to do, but I question whether you've thought of the larger implications.
it's fantastic; develop apps in a way apple can control, continuing to make the phone relatively bug free and easy to support
s60 has had an open model for years before the iPhone, and I use plenty of quality apps even without a central store running quality tests on it, let alone severely limiting developer freedom like apple has in the name of 'quality'. Limiting choices does not equate to better quality, time, effort and caring do.
Mac applications -- back when they had resource + data forks
They still do.
305MB needed to install k3b, 234MB for Amarok, and an additional 60-80 packages...
And after you installed k3b, you would find that the 234mb figure for amarok would be down to like 20mb max (just because amarok is large). By your logic with that you should include gtk+ with every gtk app you use, similar sizes would ensue. Many many apps use qt, not just a few. That you've chosen to limit yourself to gtk apps effects how many of them you know, and you only need to get QT etc once. Just like you only need to get GTK once
If it were a gigantic library that were only used for one program I could see your hesitance, however your argument seems to be, 'it wasn't in the default install on my system, so I don't want it'. Then again, most sane distributions include kde and QT with the default install with gnome and avoid that large download you mentioned anyway.
If you fail to see that 234MB of dependencies to just use a simple music player seems silly then I dont think there is a lot more I can contribute to this thread.
Every high end gui app has heaps of dependencies. To think it doesn't is ludicrous, do an ldd on gedit a simple text editor and look at all of that. To a person without gtk, you'd be looking at a similar size of libraries just for a mere text editor, do I count the text editor as being that large, no, I concede that the library is useful for other things it may enable me to run, and install it, then suddenly everything works.
The solution is for everyone to have both sets of libraries, more or less. If my current machine from 2002 (don't game so didn't see the point in upgrading) can handle it I'm guessing yours can sacrifice the 300mb of storage and a hundred or so mb of ram to run any program you find useful.
They don't want both vast sets of libraries eating up all their resources. Either Gnome or KDE is a resource pig, running a good chunk of the libraries of both is a nightmare.
I'm doing so on a machine made in 2002 as my main machine (don't game so don't see the point in upgrading) And I see no issue. Most people I know upgrade their machines a lot more frequently and place usability and functionality over 'oh noes, 100mb more ram in use'.
From what the proponents of gtk only systems say, you'd think that using qt takes up gigs of ram, it doesn't.
I fail to see why so many people using gnome hate anything that uses QT/kde libraries with such a passion. By doing so you are seriously limiting yourself and overlooking some nice software.
Amarok, k3b, k9copy (only decent dvd ripper I've found on linux suitable for recommending to others), konqueror (meh as a web browser but great for viewing local filesystem and sftp'ing with other machines, like a swiss army knife), kino for converting dv cam footage. etc.
The recent trend over the last few years for everyone to default to gnome and nobody having used any qt stuff seems strange to me, I always have both sets of libraries installed and use the best tool for the job.
and now have an HP 50G calculator running off 4 AA batteries with a faster ARM CPU. I do appreciate the architecture and power efficiency of ARM designs.
Are hp still emulating the saturn processor on their arm devices? while I understand with that model they are aiming for backwards compatibility. Attaching an arm clocked at 75mhz to a measly 512kb of ram and a 131x80 pixel screen seems ridiculous.
I know it's just a calculator and there to get the job done, but native code is nice and quick and using less cpu power lets the batteries last longer.
The TI nspire seems to be the only graphic calculator out there with a modern design.
replying to undo accidental bad moderation
How does the DRM affect you? It's merely there to enable/ you to play DRM'd files. It doesn't restrict you with anything. But if you have such files, it allows you to play them. How is that worse than Linux where you can't play them at all?
First off, drm is flawed since the content to be displayed has to be shown to the same person you're trying to obfuscate it from somehow
How does this related to linux? for the DRM to be effective you would have to stop people modifying the kernel since then they could just strip things of drm and write the resulting output to disk.. bam, drm removal done.
So either drm is supported in a way that lets you effectively completely remove drm (most people wouldn't mind this) or they try to completely lock you out of tinkering with your own system in the name of protecting the drm. That is what people have issue with.
Strange thing is most modern attempts at voice acting pale in comparison to when it was first starting
Take jon irenicus from baldur's gate 2, best voiced character ever
That we don't have any better these days is just a shame.
and my guess is that if you've done any at all, its been to the open source world where its expected that someone somewhere will have to hunt down all the dependencies that you so flagrantly didnt bother to include.
Well having your programs in the main repository IS a major advantage to code re-use, having everyone link to common code with clear cut dependencies that are automagically handled is convenient
Shipping naked executables with none of its dependencies is amateur and unrealistic, so in the real world dynamic linking does not reduce the number of bytes needing to be distributed, that quite the contrary it increases the number of bytes needed.
Depends on the method of distribution, to argue that the linux yum/apt way of installing software is wasteful with dynamic libraries is a very hard argument to defend. Windows has crap all commonly distributed useful libraries so it's all statically linked because each author thinks "bah, what user of my software would already have it installed" thusly it never gets installed, repeat.
Even in a far from ideal windows environment, there is nothing stopping your installer from checking at install time if dependencies are there, if they are at least the required version, and if not launching another installer for the library. Yes The distribution of bytes would be larger but the actual installed size would be smaller due to it only ever being installed once.
Remember when directx was new and launchers would offer to install directx? similar but with libraries and more auto-detection
You offering up scenarios where it makes sense to dynamic link, but completely ignoring all the cases where it makes no sense at all.
If you read the post above my initial one, I was responding to this:
Bottom line: dynamic libraries are, in nearly all cases, just a horrible mistake that history has yet to correct.
Considering the way the linux software ecosystem works, it's hard to say that it's horrible for all cases yes? considering dynamic linking is the default way to do things for efficiency and it all just works.
Of course I'll grant you that for extremely obscure 'no-one is really going to need this' libraries, on windows. Static linking could be quite preferable. Especially when the libraries are proprietary and not meant for reuse.
The problem under discussion is that the decision to static link is much worse than it should be, even much worse than it used to be.. that static linking has gone downhill into bloatedness for no good reason other than lazy library organization and poorly written linkers.
I stepped in when I heard someone pipe up saying dynamic linking sucked for nearly all situations, for windows machines perhaps but far from it in linux/bsd/etc.
Given the number of functions in a library like libc and the number of programs likely to need each of them at any given time, that is probably the least convincing argument ever made for using dynamic libraries.
Every process you run is using a shared library of some description usually quite a few of them, use ldd to figure it out yourself.
Your argument basically comes down to every single program should completely reinvent the wheel by including the code to do absolutely everything itself, that, is insane.
Yes you wouldn't be writing it yourself, but you are distributing hundreds of the exact same library, in a place (in binary) where it cannot be updated
Moreover, other than for near-universal functionality like libc or your basic OS integration stuff, how many libraries are really used by several different programs at the same time anyway?
at what artbitrary point do you stop calling it 'os integration stuff' when it all comes stock with most distros, I mean arguably qt and gtk are libraries separate to the 'os' same with SDL, crystalspace etc, then you go onto specific function support like libacl, libpthread, sockets, etc all of which are libraries on top of the kernel and with every linux distro.
Library re-use is everywhere in the linux world, to think it isn't is insane.
Next up, we have performance, or rather lack of it, since you can't globally optimise over code linked to a standard library the way you can to code linked statically.
So... you are really going to 'optimize' things from a completely foreign codebase that you have had no prior experience to on the source tree... to try and 'improve' performance on a single part for your needs?
You would be better off writing the needed functionality yourself from scratch in that instance, and we all know how well that goes.
Bottom line: dynamic libraries are, in nearly all cases, just a horrible mistake that history has yet to correct.
I for one, do not want the gigantic mess that is having everything statically compiled. From a deployment perspective on a system that likely won't have installed libraries, it's useful, but the real solution is to.. install the libraries.
you really want every single QT app including it's own version of QT? fine, add 30mb or so to every single app that uses it's gui, same deal with gtk.
Here's a real life program example where dynamic libraries solved a problem. Neverwinter nights, had a linux release, it used SDL for the interface and loaded the library dynamically.
If it were static, the new outputs for sound output in SDL would not be available, but since it was dynamic, the new version can be used and huzzah we have jack and pulseaudio support.
On top of that, many applications wind up depending on subtly different versions of dynamic libraries,
This, is why there's a different .so extension for each time they break the api (if it's a well thought out api this should only happen once in a blue moon) This api compatibility through the symbol tables are how dynamic libraries work, and why they work so well.
#hello world tiny program
.data
.text
.equ SYSCALL, 0x80
.equ SYS_EXIT, 1
.equ SYS_WRITE, 4
.equ STDOUT, 1
.section
hello:
.ascii "hello world!\n"
.section
.globl _start
_start:
movb $SYS_WRITE, %al #put write syscall in eax
movb $STDOUT, %bl #set stream to stdout
movl $hello, %ecx #give address of start of buffer to print
movb $13, %dl #how many characters of buffer to print
int $SYSCALL
movb $SYS_EXIT, %al
int $SYSCALL
The above is a tiny hello world program i wrote myself, it's worth noting that even the resulting binary is larger than it needs to be, I wound up with a 133 byte binary by moving the text string into the ELF header via hex editor, and changing the instruction data to point to the new addresses.
Kind of hard to get it smaller than that while keeping it in ELF format, considering the actual object code in the binary was something like 15 bytes with the data illegally in the header.
pc games are up to $110AUD ($100USD) here in australia.. and you people think $60USD for a game is insane...
Nobody has a moral right to do crime
Crimes, or committing 'offences' are defined by law, law and morality often conflict, not to mention it is practically impossible for any given person to know all laws
According to law, ignorance of the law is not an excuse for breaking it, while morals vary between the person there tends to be common understood standards for most things in a society. I would argue that if a law is unknown to you, and you do something that a majority of your peers would consider moral, if not legal, it should be justification.
Even upon knowing the law and willingly breaking it it can be justified, in some places it's illegal to copy government documents on the local laws due to 'copyright' could you honestly argue that it is immoral to break that copyright in order to share the information with the people who are beholden to those laws?
There comes a point where laws must be broken, granted copying movies isn't that point (for me, and most people), but to say there is no moral right to do any crime is a hard sell, when any given action can be described as a crime by the state.
The only tough Apple products to work on nowadays are some of the ipods. (the "ipod classic" comes immediately to mind)
And the ipod touch, etc, not sure about you but I get a craptonne more ipod service requests than actual mac computer ones, I agree mac pro's aren't difficult to service but compare how many people have mac pros compared to ipods, etc.
As for "1mm screws", that's almost funny to read.
See ipod touch for that one
Where are you pulling your arseformation out of anyway?
From a friend who has been an apple service provider for about fifteen years, and disassembly of imacs/ipods etc myself.
You must be new to apple service. I've been at it for going on 10 years. I'll take a new mac to work on any day over an old one. 40+ screws of 15 different sizes in random places to replace the logic board in a clamshell ibook from '98 is a great example.
Oh I already know how bitchingly difficult some of the old g3's etc could be, just because their main product line is a lot easier than it used to be doesn't mean it's not ridiculous compared to other modern machines.
Putty knife with the mac mini anyone?
To be fair my hatred of apples methods of keeping people out probably stems from the sheer amount of ipod classics and touches I have to fix compared to other apple hardware, fact is those are their most popular products though.
Today I do warranty repair work for Apple at an AASP.
Dear god you must enjoy pain, as newer apple products come out they continue to progress towards 'no user servicable parts' with more and more annoying ways to keep people out of them (1mm phillips screws etc etc)
As a tinkerer/fixer of things it must be frustrating to work with such hostile hardware.
How does a stable ABI product drivers, I'll tell you how, by making it trivial for the companies to support you!
This involves some very large assumptions, you are assuming it is extremely difficult to get stable tested drivers into mainline, and you are assuming that having a stable ABI will somehow make life easier. They still have to release source anyway, so why not get it into mainline? at which point having a stable abi means nothing.
Newsflash: even with a stable ABI some vendors *gasp* won't release linux drivers, and even if a perfect OSS driver is made, the vendor could still not say it works on linux in the packaging
You seem to hate the very idea of drivers being in the kernel at all. Also seeming to lack understanding of how drivers work in the linux kernel, they go by chipset not by device id thusly a single driver can support hundreds of devices that are practically identical except for the company that made them. Each vendor wouldn't have to release a driver like they do with windows, only the chipset manufacturer would (and they do, why do you think 95% of common hardware is supported out of the box on linux) and once devices are released with the chipset their device ID is added to the driver saying if this hardware appears, use this driver.
This results in the benefit that if the vendor of your hardware goes out of business quickly, or just ditches you, you aren't stuck, drivers are still actively maintained, as opposed to possibly getting stuck with crappy drivers that could bring down the system.
Most common devices conform to specifications, i.e. webcams conforming to USB video and the like, thus work straight up.
In the end having drivers in kernel stops all of the fucking around you have to do on other systems like windows.
while Linux zealots argue whether they should allow binary blobs or not they are about to get train fucked and don't even know it! How, you may ask? by a little piece of MSFT engineering known as ExFAT [wikipedia.org] that's how? It is patented up the ass, which means no more free shit, and all the flash based devices will be switched over in about 3 years. hell even the last 8Gb drive I picked up at Big Lots had ExFAT and a driver CD. See, there is that pesky "drivers on CDs" thing again.
The only notable advantage of exFat over fat32 is the larger than 4gig single file support, and by formatting it as that you essentially kill all current forms of portable device support, fat32 will still live for quite some time to come because of all the embedded support. Portable hard disks already use ntfs which linux can use. And there has been an open source read only driver for linux for exfat since the beggining of 2009 with write forthcoming, haven't encountered any devices that use it yet myself. To think this is a show-stopper is extremely naive.
Regardless, it is apparent that you really don't care how things work, why they work, or have any real clue as to why things are the way they are (hint: it's not because everyone happy and using linux are 'linux elitists')
You expect everything to work the way that windows and to a much lesser extent mac os x do, and the fact is linux is a very different design and what works for them would not work for linux.
Again you completely ignore every single thing I wrote.
It was read in entirety, but as said I only commented on the parts relevant to the scope of the argument (stable ABI) You are the one that keeps trying to up the scope to the whole "linux is not ready for the desktop" business. I have no interest in changing scope or changing what is being discussed. Perhaps it is my fault for responding to some of the off topic parts.
And funny you should mention FSF, which of course is headed up by RMS, the most left wing radical zealot on the face of the planet. do you know what "PC" he runs? I do, it is a Loongson Netbook, because it is the ONLY machine on the entire planet that will meet his radical idea of "free", why do you people still take advice from that nut?
What makes you think I take advice from him? All I said was a likely course of action from the FSF if something came to pass, which you have to admit given their stances they would likely do. Throughout this conversation you always assume much in certain ways when I have given you little reason to do so.
I already pointed out your putting kernel numbers, which would be like expecting Windows users to know which kernel and patch level their PC was up to, is a complete waste of time, because by the time the device hits market it will already be far out of date.
Here's a thought, say your stable ABI is implemented, you put a linux sticker on, now someone sees this and tries to install it on their ancient 2.6.13 linux install (obviously with no abi support) it has the linux sticker doesn't it? the driver on the disc should work shouldn't it? even in your scenario, a version number would be required.
Also, you mostly missed the point with that especially judging by your "because by the time the device hits market it will already be far out of date." the idea would be to put the kernel version the driver went to mainline in, so you don't need that particular version, that or anything newer would function just fine.
And yes, with vendor support hardware is added to mainline kernel all the time BEFORE the hardware is even released, so when packaging is being made you could know what the minimum version is etc
So I am curious to hear your non ABI solution.
See above, the hardware would show it supported linux and how recent the version has to be for it to work seamlessly.
This would require nothing from the part of developers, all that is needed is a logo and the version number put on the box to hardware that has support. Ironically I have found hardware with such details already, but in the extreme minority. For it to happen the vendor has to have an interest in caring enough to even recognize linux support when it's been made by others etc, so you'll never have logos on all the equipment supported, but you would be guaranteed the items that did worked for that version and later.
Now for the side-track questions..
Now here is a question for you? How much time did you waste researching products before purchase? 5 hours? 6?
I never research before buying, when it comes to motherboard/cpu/videocard/sound... and yes, I haven't had a single piece of software not work for a base computer, could say I'm lucky, but I've went through five very different machines all to the same effect.
And when was the last time you fired up bash...hmmm? Last month? Last week? Today?
I always have four or five terminals open, mostly because I don't close windows for weeks, and that my work is faster with it than a gui, sure I could do without it, but why limit myself and make my day to day activities slower and harder?
such as the Linux user that told me with a straight face I should force Joe and Sally average to "embrace the power!" of CLI. damn, that still cracks me up.
No end user common task has need
Oh just one more thing
what, you gonna end up shipping on 14 DVDs? You DO know that the number of devices continues to go UP and not down, right?
The entirely of the linux kernel with full support for 20 years worth of equipment comes to 30mb... I have seen single windows drivers that were over 100mb in size, while that was inefficient even a well written windows driver would be somewhat larger than the linux one, because linux driver components reuse themselves, and makes driver writing that much simpler.
Have to write a driver for a new wifi card? the 80211 stack is already there, basically everything is, all you would have to write is device specific things like telling the existing infrastructure how the memory map of the device works, and where the registers and buffers are etc.
Somewhat better than reinventing the wheel with every driver, yes?
Again, most of your post is irrelevant to the topic in discussion, but I'll respond to the relevant parts
I notice you didn't link to the discussion, and I know why,because I have already read it.
Actually it was because I was time constrained and on a device with limited bandwidth (phone) some people do work at work.. sometimes :) don't jump to conclusions
While not exactly the thread I was meaning, this (notably c.2.2) contains part of what I meant.
Still am rather short on time, but the gist of it was more or less a stable ABI greatly limits what the kernel developers can do, i.e. if the most efficient way to do something breaks it, or they need to implement extra functionality that would break it, they can't. Linus doesn't want his hands tied
On a tangent to the link I mentioned (well.. slightly related I guess) is the following Any device driver that was written specifically for linux is by default under the GPL license when distributed, while linus wouldn't enforce this on things he does not consider derived works, you can bet your ass the FSF would if linux specific binary blobs became common, so even with a stable ABI, source would have to be provided anyway.
This isn't really a problem because vendors who do write linux drivers tend to provide source anyway.. that gets into mainline in time. If they have to release source anyway (in 99% of cases) why have a limiting stable ABI?
"Linux is free if your time is worthless"
Silly question, how long does it take you to install office, visual studio 2008, photoshop (or gimp, or whatever) a bittorrent client, a decent cd burning program.. the list goes on. Windows is FAR from complete out of the box, and it doesn't even have a nice repository like system to install things, overall install time is ridiculous to get a functional system for people that actually want to do things besides ms paint.
You still say the linux kernel devs are just 'elitist' because they won't pander to what you want even though what you want results in a poor engineering decision.
the argument for a stable ABI came up in 1993 or so, feel free to check the lkml archives on the topic, there are reasons for why things are the way they are now. This is not a dictatorship, sound technical decisions take precedence over almost all else.You may see this as 'elitist' but it's more just pragmatism.
Of course the irony of it all is that linux has the widest range of hardware support of basically any os out of the box because of the way it's designed
It is actually quite simple, having a stble ABI would mean that device manufacturers could write once, use for years, as they currently enjoy with Windows and OSX
This also means users have to hunt down said driver, install it, and also that it will at some point be completely useless when that particular ABI is thrown out, a few years down the track.
with Linux I have to give up control to some guy and pray he doesn't fuck me or spend crazy money constantly cranking out new drivers.
You know that in house company drivers are accepted into the linux kernel yes? the only requirements are related to code style (not a problem if you've aimed to get it included from the start, which you should be if you are writing a linux driver) and quality. While people are free to make their own versions etc you can be paying the maintainer and he could be an employee.
Same deal as windows more or less except your source code is open, and you have a couple of restraints in regard to style, but ending in something much more useful
Now before you say "What if Windows comes out with a new version 6 years from now"? Well I don't care, because by then my device will long be off the shelves and I don't support dumpster divers.
You may like forced obsolescence and everything only being short term, but I for one do not. (one of my main boxes was made in 2002, still running latest linux etc just fine) people don't like it when their hardware becomes unsupported for no good reason besides 'buy new stuff'.
But then we get to Linux. to support Linux first of all I can't do the logical thing, which is write a driver and put in on the CD,
This is only logical to windows users, ideally you should never have to install drivers. In the days of yore everything was running out of the box albeit with rather fixed systems.
followed by MSFT releasing a nearly decade old WinXP onto the lanscape, which promptly completely slaughtered.
People like what is familiar, people also like playing games, this is the same reason mac machine sales greatly increased after it became possibly to easily install windows on them, this is not unique to linux
All hardware vendors have a vested interest in making the software that runs on their hardware cheap, because it enables people to buy more hardware. End users buy very little comparatively to HPC because they don't need it and/or don't have the money. It's a simple thing of how much more hardware will we sell if we support the extra os, for anything high end like cad users, hpc, this is high, low end for there to be incentive you need large numbers of the small orders, which as you say linux does not yet have.
where we will prove Linux at retail is a giant clusterfuck!
This is not the point I disagreed with you with, you should be arguing how a stable ABI will fix the driver situation, which you so clearly stated earlier it magically would. Which is what I disagreed about. There is a myriad of problems with selling linux to average consumers in non-appliance form of course.
The fact is, having a stable ABI would create more problems than it solves, and fails to solve what you wanted resolve anyway (better/more drivers).
No go to the "big three" Walmart.com, staples.com, and Bestbuy.com, and place these three things in your cart, remember NO research! Place a USB wifi stick, a USB TV Tuner, and a USB all in one printer.
Printers I'll give you, never bought a random one because I like true postscript printers that aren't exactly consumer goods. But I buy random usb wifi sticks with no research all the time, and either I'm just lucky or they all work these days, I only started doing that in 2006 or so so prior to that it probably was a clusterfuck. TV tuners can't say I have any usb ones but I have a cheap ass chinese pci one that I don't even know the brand of that works here, which ironically I can't even get to work on windows (on the version it was designed for too). But can't say that's consistent because I don't go out and buy tv tuner cards all the time etc.
But ironically, although i've answered your question, all of the above is moot, because you have still failed to address how having a stable ABI would somehow make drivers magically appear. Your initial argument was that having a stable ABI
And you mention Nvidia? Can I laugh now? Do you have any idea how much $$$ Nvidia spends having to constantly update their drivers just so they'll continue working?
You do realize that the base of the nvidia linux drivers are essentially the same as the windows driver.. right? Yes they spend a bit of money on linux specific interfaces like vdpau, but that's hardly the kernels 'fault' they are putting new functionality in their drivers yes?
Linux guys will still scream "Next year is the year of Linux on the desktop!"
The 'year of the linux desktop' imho is not so much a single year where everyone uptakes linux, but rather like a curve, different people have different needs etc, and every year linux fulfils a slightly larger subset of those needs. Linux adoption will be gradual, and generally only by those who care enough to even look into it.
In a decade OSX will be around 10%
Now that IS a very bold claim, for every five people I see with a macbook on average only one of them is running OS X, they may achieve that much in hardware sales in the future, but actual people running os x? bold prediction
And as a retailer I just think it is a damned shame, but I'm not gonna go bankrupt trying to support your OS when you can't even get a stupid penguin put on the boxes at walmart.
And nobody ever asked you to, if it doesn't make business sense don't do it. If you re-read my posts my only gripe with your posting is the belief having a stable ABI is some kind of magic bullet to fix the problems at retail, it really isn't and even if you somehow had full hardware compatibility with linux(and a stable ABI would not do that), you would still have higher return rates etc and other problems.
heh, I don't have the time to waste with people like you, continue to believe as you wish, but the fact you said
Your "things won't change!" argument. Well no shit.
And you still wanting to implement a failed strategy is quite telling
Your arguments are full of elitism and full of fail. Watch as I blow them completely out of the water.
Cocky one aren't we much? considering your post has little to no real content
1.-Having the kernel devs do it-Total fail, because your kernel devs should be...oh I don't know....actually working on the KERNEL instead of playing driver fixit boy,
Have you LOOKED at the kernel source or changelogs any time lately? Drivers are by far the majority of the kernel, and it's by far most of what is worked on. By most accounts the linux kernel is a fair way to 'done' with most companies and users being happy with the non-driver feature set with there being little else to add besides driver support.
Most of the new items always will be drivers, because the quality improvements of being in mainline are real, and even you would have to agree attaching a piece of hardware and having it just work is better than actually having to install anything.
This animosity to BETTER driver support seems strange to me, considering you were bitching about it.
If I am a manufacturer, I can write just 4 drivers, that's right, just 4 drivers, and cover Windows for a decade and a half...2K/XP32, XPx64/2K3x64, Vista/7 ,Vista/7x64. See?
how many manufacturers do this, especially if a new windows version comes out say, two or three years after the hardware is released, answer: fuck all. The hardware is then useless to those who aren't willing to have a separate machine to run the old os. Same with xp supported hardware these days, it's going the way of the dodo, everything wants vista and up because no drivers are written for xp any more.
Linux, on the other hand, is a complete and total clusterfuck where I have to either give all my code to some guy and hope like hell he gets off his ass quick enough to get the driver into mainline before my device is no longer sold, and any driver I release my self on the CD with Windows and OSX will in all likelihood NOT WORK by the time it hits the shelves.
Ever used the nvidia binary blob installer? it's quite possibly to have a small open source compatibility layer that functions for *gasp* many different kernels, inefficient way to do it, but if you _need_ closed source, it has been done before while maintaining compatibility with newer versions
And don't forget we are talking a year to 2 years before a device goes from designed to on your shelves, and the average Ubuntu is how long again? Six months? See the problem here?
Not in the slightest, if anything it's a good thing because it gives you plenty of time to make a driver that works, sane drivers once written will continue to work, amazingly every driver isn't rewritten every kernel version, to do so would be ludicrous. Your insistence on a stable ABI while making life easier in the short term would architecturally compromise things in the kernel.
Sorry but the entire Linux method ATM is nothing but a fail whale.
Well, you may say it's 'linux elitism' but the way things work currently works for millions of (mostly technically literate, but increasing number not) users, we depend on the quality control of the mainline devs a lot, if a company isn't willing to write drivers that work with multiple kernel versions (just a compile away with the right abstractions) why should we trust the quality of such a shoddy product in the first place?
So much for 'blowing my argument out of the water' the almost childish use of language at times combined with not actually addressing any of the points I raised does not an argument make.
European powers (England at the time, but there was also France and Spain)
France bankrupted itself supporting the colonists against the british, spending only 20% less than the british did themselves in the endeavour. (in the realm of a hundred million pounds in 1700's money) Which prompted the events of bastille day.
A lot of sheer luck enabled the US to become independent, England has other fish to fry and a lot of disadvantages in regards to long communication times, having to leave troops in captured territory so that the revolutionaries wouldn't just return, etc
Again with the stable ABI argument, we've had this discussion before (hmm should maybe pay slashdot so I can access my full posting history *sigh*) and I thought I managed to get you to concede that even having a stable ABI would not solve a thing.
stable ABI so the driver they write a year ago when the device was made will work now,
If the driver is in mainline, when they plug it in it will just 'magically' work, better than windows or os x on many fronts
With very few exceptions (nvidia mostly) if they aren't willing to write an open source driver for linux, they aren't willing to write a closed source one either.
By having a stable ABI you are forcing kernel developers to wind up making unnecessary compatibility layers to the 'real' functions when they inevitably change at some arbitrary point in the future. You limit exposure of future kernel functions, and everyone winds up reinventing the wheel.
To add insult to injury, you would lack the quality control of the mainline kernel and wind up with a situation similar to windows in which bad drivers bring down the system.
So while the ABI proposal fails at it's main purpose (getting more linux drivers) it also from a technical viewpoint adds unnecessary complexity to an already complex system with no benefit.
Still agree with your branding proposal though otherwise, only everything with the linux branding would have to be in mainline when released, with minimum kernel version listed on box, thus they wouldn't even have to ship drivers on cd, the hardware would be guaranteed to 'just work'
So far as the return rates, The majority of people that would just purchase a pc would not know what linux is to start with, and likely didn't know what they were getting into. Those that do probably want to install your own flavours so selecting supported hardware is more the service they'd pay for.
The young (children) and the elderly who don't play games are the best candidates for linux, but they aren't the ones who buy the most computers.
Ironically, one of the biggest strengths of linux is that when hardware does work, it continues to work, MFM hard drives were only just discontinued in mainline, even though said hardware is basically from the 80's
I dare you to attempt to get a printer from 1998 working on windows 7, it will make any linux troubles you have had look like childsplay.
In summary, you seem to be willing to throw the baby out with the bath water thinking a stable ABI will be a magic solution, if it were truly beneficial it would have already happened, the negatives are too great and the perceived benefits are simply not there.