"It's been mentioned over and over- the "netbooks" are moving upmarket as simply "cheap laptops.""
++. Yes. This really annoyed me when I went shopping. The first eeePC was NZ$600 here, but now there's practically nothing under NZ$1000, and the specs are approaching generic laptops. 160 GB HD minimum. The portability is nice, but I would have liked a cheaper, smaller option - why am I going to put 160 GB of media onto something with a hard drive which might go 'pfft' any moment? I'd actually prefer a smaller, more rugged drive, if that's possible.
(Leaving aside the question that still hovers over the iPod: just how much money would I have to pay to legitimately purchase 160GB worth of music/TV from iTunes?)
They aren't, here in New Zealand. The first generation eeePCs were a year ago, but not any more. I shopped around several local computer outlets a month ago looking specifically for a current late-2009 netbook running Linux. Acer AspireOne, Asus eeePC, HP mini. They all said 'sorry, there may be a Linux version available in the States but we only import the Windows one.'
So I bought a Windows one and installed Ubuntu Jaunty Netbook Remix on it - but I was annoyed that I had to bump the Windows stats by one, and pay for a licence I'm not going to use, AND not get an officially supported Linux, to do that.
"Systems with significant feedback are extremely difficult to model usefully. In cases where the model does not converge, it's impossible. THAT's why they don't do it."
However, reality is under no compulsion to care about the ease of computation of your model. And models which are known not to correctly describe reality but are followed anyway are not only not useful, they're actively malicious.
"Any economic model which is computable is not the true economic model" should be either a Zen koan or Murphy's law. Or both. And it should be inscribed on the foreheads of everyone working in finance today.
Oh - right. Rereading the Ultimatum Game, there's a very simple, very obvious way the 1-cent / 99-cent deal is abusive:
If I agree to the 1 cent, I not only get 1 cent *but you gain 99 cents*. That's NOT just money I don't get - it's POWER which goes to you, which you can then use *against* me (ie, you could use it to buy guns, hire armies to directly attack me, or even just build fences to deny me resources)..
But if I veto the deal, the power differential remains unchanged. I might suffer a little because of the immediate lack of resources - but I don't suffer the massive, immediate power loss to you. You don't get to buy any guns or build any fences; I'm 98 whole cents safer.
The choice to me is NOT just 1 cent vs 0 cents - it's -98 cents worth of power differential vs 0 cents of power differential. And that's a very clear, very obvious, very logical choice to make. And it's something completely missed by Austrian school economists, who make the completely unjustified assumption that economic power always and totally represents innocent self-enhancement, rather than social power which can be used against enemies.
The obvious parallel is outsourcing of data centres and 'software as a service'. Shipping my data to your data centre in India might be cheaper than processing it inhouse, so if I take that deal I get free money. Yay! But there's an immediate security cost to me; you now get my data. With that data, you could do any amount of damage to me. How much is the security of you not having my data worth in dollars?
The sense of 'pride' is not illogical in the least - it's all about security and safety in a dangerous world where you can't always trust your economic partners, and where accumulation of money and social power is a double-edged sword which can be turned into either creative wealth or destructive force - *by* rational economic dealers.
The use of force itself can be economically rational, again something Austrian school economics ignores. In a monopoly situation, if I use force against my competitors to eliminate them, I can get higher rents. So a Prisoner's Dilemma type situation emerges in any market where purchasable force (even passive, denial-of-potential-resources force like fences or colonies) is an option.
"if Person A doesn't offer enough to B (say, 20%), Person B tends to reject it, whether out of spite, or a sense of fairness. "
"Most of these financial models, in essence, assume people are Vulcans, when they're not - they're people"
I suspect that even if people *were* Vulcans, they still wouldn't act like Economic Man. The problem with 'thinking on the margin' and always taking that 1 cent regardless of the power differential it sets up, is that Real Life Isn't Like That. Specifically, each economic transaction NEVER exists in a vacuum - which seems to be the main assumption of margin thinking.
Instead, each economic transaction is a single step embedded in a very complex ongoing power game. For example, if I agree to that 1 cent deal, I haven't just made 1 cent I would otherwise have made; I've also given up something in return: I've paid the time and/or resource cost to take part in that transaction, and I've signalled my agreement with your agenda, a signal which may then be broadcast to the group and amplified as future mass behaviour. I've engaged in submission behaviour and established a precedent. In 'emotional' terns, I've lost 'pride' or 'face' - but that's not just an illogical squishy feeling, it's a real matter of social status and trust. The intuitive feeling is that by agreeing to an 'abusive' deal like that, I've somehow squandered my future status and granted my consent to a power differential which could lead to abuse or even ral physical danger; I suspect that this feeling would be mathematically justifiable if we ran the appropriate simulations of group behaviour and resource allocation.
The resource commitment is the most obvious way the 1-cent deal is abusive - in reality transactions are never zero-cost, so there's always an opportunity cost - but there's something else nasty going on, too which is harder to put my finger on. The 'precedent' problem is likely due to the fact that *calculating the cost of decisions* costs nonzero resources, so we tend to make decisions in bundles and as groups - which means that bargaining becomes not just a per-transaction negoatiation, but a matter of dominating the 'choke points' in the decision-making process. Accepting a less-than-fair deal therefore means devaluing future transactions (even by marginal thinking this makes sense, if we assume that all transactions are made based not on *absolute* figures but on changes relative to the current state - again, this probably requires taking into account the fact that every change itself costs resources).
I think there would be a lot of interesting economic science to be done by analysing the mathematics behind our social intuitions. I strongly suspect that something like 'tribal' behaviour will naturally emerge as the most efficient way to make economic decisions, and explain why Austrian school economics is flawed. Assigning a cost to both information and computation (similar to Joseph Stiglitz' research on information assymetry) seems like a good place to start.
Info is, what, vi for documentation? And I don't use vi for anything else, so I can never remember the weird keystrokes to even exit the thing. If non-man documentation were HTML... heck, even read via lynx/links... that would be sensible.
"The second reason is that Ubuntu is an unstable distro, which means that the software gets updated a lot, including the kernel. The way ndiswrapper works, is that part of it, is a userland app and another part of it is a kernel modue. The kernel module has to be recompiled every time you upgrade your kernel because of the way ndiswrapper is designed."
That's an explanation, not a solution - and tends to support the parent poster's argument.
It fundamentally IS NOT RELEVANT what technical arguments can be made to support a particular design, if the upshot is that that design DOES NOT DELIVER a functional system.
Where 'functional' in this case means 'the system should at all times work with currently shipping bulk-retail hardware.'
It just doesn't matter what technical reasons may or may not hold why Linux doesn't work with Currently Selling Widget X. If it does not work for User Z with Currently Selling Widget X, then that's a bug and needs to be fixed.
Whether the ultimate solution is social, technical, economic, or leglislative also doesn't matter. The implementation of the fix doesn't matter. The only thing that matters is that User Z can't use Linux to do what she needs it to do. If she can't, she'll buy Windows or OSX instead, because having a working system trumps every other alternative.
"If you run XP on a MacBook or build a 'Hackintosh' you are going to have to be sure you have supported hardware.
Why should anyone expect different from linux? Just because it very often "Just works" on linux doesn't mean it always has to. "
That would be fine if you could get 'certified for Linux' hardware as a Just Works option, like you can for Windows or OS X, and pursue 'hacking your own' as a sideline.
But you generally can't. Even the netbooks that once shipped with customised Linux now aren't available with anything other than Windows. At least here in NZ they aren't. Try getting a new Aspire or eeePC with an official, supported Linux in 2009.
This fundamental lack of hardware support makes Linux an also-ran when you're purchasing at a corporate level.
As a data point, my Quickcam seems to randomly stop working about every second Ubuntu update. I've been running Linux since Red Hat 5, moved to Ubuntu when the Great Fedora Fork happened, used to compile my own sbca driver, and things are *slightly* better now for webcam support than they were ten years ago... but only slightly. Random weird driver breakage between versions just seems to happen and it's a case of shrug and deal with it by Googling forums for several hours and copy-pasting cryptic command lines that you hope are relevant and won't break even more stuff.
Okay, so I can do this. Except I'm getting mighty sick of it. Not sick enough to leave Ubuntu, but still, it's a drag.
Similarly, the Hardy-Intrepid-Jaunty update killed my sound for no good reason other than Ubuntu's upgrade process wasn't smart enough to install the right.debs for full PulseAudio support. Again, no big... as long as I was comfortable wading through techy forum stuff I didn't really understand myself. PulseAudio seems to have so many more dials and knobs and pathways for things to get broken between sound card and application that it's much harder to even begin to understand what might be wrong.
These sort of things might be the price of upgrades, but they still seem to be regressions in overall software quality, and that's worrisome. We're putting more effort than ever into the Linux desktop experience, and sometimes getting LESS than zero improvement.
"Imagine what would happen if someone takes this shit seriously, and gets a descent core.."
A 3D user interface where you have to fly upside down through asteroid tunnel systems rescuing your hostage files, and to shut down you shoot the nuclear reactor?
"If you're a programmer writing programms for other programmers, you want all output and input to be in the form of ASCII or UTF-8 text, so that it is easilly manipulated by other programs"
"With programs written for programmers, the GUI is usually tacked on after the fact just to help users use the program"
While I agree with this assessment, I'd like to dig a little deeper into *why* this is so.
I think the problem is that our current GUI model/metaphor is fundamentally broken (or lacking an important feature). Our GUIs are not expressive enough - they are not as expressive as plain text, nor are they composable like text is. This has been seen as an acceptable tradeoff because GUIs are seen as fundamentally 'for the user', not 'for the programmer'. And this creates the big divide between users and programmers.
But what if the GUI could be made compositionally complete?
It frustrates me that GUI development essentially stagnated right after the Xerox Star created the 'icon' and 'folder' metaphor. That was a good mapping of the hierarchical Unix filesystem onto a 'desktop' visual metaphor - but it did nothing for the rest of the system, it did nothing for processes, or for visually mapping arbitrary code/data. We still had to use text for that.
What if we could reinvent or extend GUIs so that they were precisely as powerful as a text config file or C++ code? Some kind of node-based or list-based or pipe-based visual abstraction which we could then manipulate and especially compose in EXACTLY the same way a programmer would compose Unix batch files?
I'm thinking something like XSLT transformations. Maybe not exactly, but that sort of thing. If the GUI were *just* and only just a view of an underlying (dynamic) data/computation structure.
Then we wouldn't have to choose between 'text' or 'GUI'. It would be simply 'data' and 'view of data'.
Yeah, I know things like progress bars complicate the matter. A GUI-like 'view' of a process is necessarily event-based, interactive and incremental, while a text-like view is usually sequential and deals with whole blocks of data at a time. But I don't think it's fundamentally unthinkable. What if we took, for instance, Unix pipes, and made them streams of *events* represented as text? Then you could pipe a text file or syslog through a filter which generated on the fly an interactive GUI grid-view.
Our current 'but you have to first start a new SVN project, then code an application which creates a dialog box and runs an event loop, then compile it, then link it, then install it into your system, then launch it, then have it read the data from a file...' mentality stops us doing this sort of thing. Which is why I think that workflow has to change. We have to be able to instantiate things like custom dialog boxes completely on the fly, automatically, no compilation required. And there has to be zero data loss, zero impedance mismatch, between computer-processable and interactive representations.
"I think the solution (assuming you want to solve it) is for developers to find ways to solicit feedback from common users, and then address those issues the users find most frustrating."
What about my favourite solution: rearchitecting the framework for developing the software to make it possible for *the users themselves* to contribute small, effective, and safe changes?
I think our current 'best practice methodology' for developing applications - a hard wall between 'developers', who write in raw C/C++/C#/Java and manage nightmare issues like locks and concurrency and threads and buffer overflows, and 'users', who get to click the pretty buttons and go 'aww' at the colours, is all kinds of wrong. Yes, it works, but it dumps all the responsibility for doing everything onto the developer class, who sneer at the user class for being dumb.
Plugins help a bit - at least they allow a third class of 'plugin developer' between 'application developer' and 'end user' - and scripting languages help more - but I think we can, and should, do better. It should be dead easy, and safe, for complete end users to be able to pick up and tweak elements of the 'application' - especially the user interface - that don't work for them, or are irritating. Things like 'the dialog box is too small by five pixels', which have zero algorithmic content, should be so abstracted out of the design loop that a user could literally just click and drag a box and have it rewrite the XUL file, or whatever.
This was the Smalltalk vision, remember? That you could divide programs into 'objects' so that the user could completely - and SAFELY - customise their experience.
Yet it hasn't worked out like that, at all, for Windows OR for Mac or Linux. Doing GUI coding seems to still be horribly, insanely brittle and dangerous, so we don't trust the users to do that. We promote the use of completely different tools, workflows, and even languages for application development vs plugin or script or macro development. And we're back to a hard wall between two classes of user and developer who don't share methodologies or incentives.
But why? I think we need to rethink how we design GUI development frameworks. The current model doesn't seem to be working.
We might still be using steam, but glorification technology has advanced tremendously since the nineteenth century.
Modern glory engines generally achieve virtue ratings in the giga-archangel range on the Baden-Powell scale. The biggest problem is containment of the antikarma halo from contaminating the surrounding noosphere and uplifting our whole cultural discourse; in the worst case, this could create a self-perpetuating virtuous cycle, the so-called Shambala Syndrome. In some cases residents within fifty miles of glory stations have tested positive for elevated morals. There have even been unconfirmed reports of spontaneous canonisation, yet the International Glorification Commission still claims this technology is safe.
It's time to wake up, people. The smoking gun could come in the form of clouds and trumpets.
"No, the programmer can not solve the problem with pen and paper. It requires the hardware that is designed and built by other people. It requires the libraries that are written by others. It requires the electricity that is provided by others. The programmer would die long before he could complete the algorithm on paper and the programmer does not understand all the subsystems required to make the algorithm accurately and proficiently run."
Reread what I said. Hardware isn't required to solve *problems* as problems. Pencil and paper can do it - yes, it might require more than the programmer's lifetime, but that's not a problem since you can always train more programmers to carry on.
Solving well understood problems *in realtime*, and delegating the repetitive solving of such problems to a subsystem, yes, that's a different thing. But it's actually a very narrow subset of intelligence. My claim is that you can't replicate general intelligence by using small mechanical systems geared to do very precise calculations fast. They are fast *because* they are less general.
You're claiming that an AI HAL1, itself unable to solve a certain problem, nevertheless possesses the even more general and more powerful meta-level problem-solving ability to CREATE - conceptualise, design, implement, test and maintain - another AI HAL2 which possesses a problem-solving power HAL1 itself doesn't have.
I'm claiming that not only will prove to be physically impossible - but is in fact logically incoherent.
Libraries and algorithms written by others - okay, now you're talking about a whole different order of problem-solving: trying to get correct output without correct input. Yes, without the correct, relevant algorithms and data, no computer will be able to solve any problem. I believe this realisation is why the 1980s AI wave started to focus on 'knowledge' as the critical factor. But they ran into philosophical problems with representing (and recognising the truth/relevance/validity of ) knowledge which have still not been ironed out yet.
However, a human programmer has an advantage over a computer here: humans are in fact able to infer, guess, intuit and just plain cheat their way to recognising and creating knowledge *without* full and precise algorithms or precisely correct data. That's a capability we still haven't worked out how it works yet.
"In the same way, a team of AI computers, each with their own specialty could design better hardware and software that one AI would not be able to solve by itself."
But a single computer running VMWare could simulate that whole cluster, right?
So it's not that the AI is NOT ABLE to solve the problem by itself. It has the algorithms. It's just that it can't do it *fast* enough.
This is the very assumption that Strategic Computing was labouring under - that we already understood the core basics of 'intelligence' as symbol manipulation / expert systems / knowledge representation / inference, and the only limitation to achieving AI was knowledge base + speed.
Read the book. That turned out to be a very interestingly flawed assumption, and it led directly to the 'AI Winter' of the late 1980s / early 1990s when the DARPA funding dried up.
Bottom line is we don't actually have a very good idea at all about what 'intelligence' is. Not just 'we don't know how to make it fast enough', not just 'we don't know how to program it' but even 'we don't know how to program a computer to RECOGNISE it if it were able to program another computer to program it'.
Yo momma so associative, her Grothendieck group is isomorphic to Z for a bounded complex of finite dimensional vector spaces possessing the standard Euler characteristic.
"Ape B... is lazy, stupid and generally useless.... makes it through life by getting A type apes to do things"
If Ape B is so good at getting Ape A to do things, he's not actually stupid at all. In fact, he's probably socially a lot smarter than Ape A.
Conversely, the mere existence of Ape B shows that Ape A is deficient at organising - otherwise there'd be no niche for B to inhabit.
Moral: social intelligence is not a lesser kind of intelligence than technical intelligence. It's equally powerful and equally useful. And can be abused just as equally
"humans can only solve certain mathematical problems by building computers."
There's something missing from that sentence.
"can only solve certain mathematical problems IN A REASONABLE TIME by building computers."
We can solve the problems without computers just fine using a bunch of people in a room, like we did for the Manhattan Project (where women were literally called "computers").
We just don't like to do it that way because it's very slow, and we're impatient. But the computer gives us no results we're not otherwise CAPABLE of generating by applying the calculating rules ourselves.
One of the illusions of the 1980s Strategic Computing AI project was that all that was needed to make strong AI was to vastly speed up computers. We got the speedup - but it didn't get us AI.
This suggests that the "computers can solve problems humans can't because intelligence is a subset of calculation" argument is precisely inverted. Humans can indeed solve problems computers can't. Computers can solve a SUBSET of problems humans can - but they can do that subset much faster and more rigidly.
Intelligence may well be a superset, not a subset, of calculation.
"Somethings are greater than the sum of their parts. eg. emergent behavior, ant society, co-operatives."
That's not true in the way it's usually portrayed.
Emergent behaviour IS THE SUM of its parts, no more, no less. If the individual components do not express the fundamental laws of a system, that system will not display behaviour generated by those laws.
In other words, if HAL2 is a complex of HAL1s, and HAL2 can do something, then HAL1 always did have the capacity to do that too. It just wasn't initially obvious. But obviousness is not the same thing as identity.
Very simple laws are more powerful than you may initially assume - but the emergent system described by those laws is not 'greater' than the laws themselves. Three bodies orbiting in space are not 'greater' than the law of gravity they follow just because their motion is complex and unpredictable.
Slashdot Mirror
And yet they built some pretty good rockets despite that.
"People worship "American Idol" over Stephen Hawking, because they are SOLD and MANIPULATED these values"
I'd love to see a reality show about contestants developing their own Theory of Everything.
Geometrodynamics, I choose YOU!
(Actually I've still got a soft spot for Einstein's classical UFT.)
"It's been mentioned over and over- the "netbooks" are moving upmarket as simply "cheap laptops.""
++. Yes. This really annoyed me when I went shopping. The first eeePC was NZ$600 here, but now there's practically nothing under NZ$1000, and the specs are approaching generic laptops. 160 GB HD minimum. The portability is nice, but I would have liked a cheaper, smaller option - why am I going to put 160 GB of media onto something with a hard drive which might go 'pfft' any moment? I'd actually prefer a smaller, more rugged drive, if that's possible.
(Leaving aside the question that still hovers over the iPod: just how much money would I have to pay to legitimately purchase 160GB worth of music/TV from iTunes?)
They aren't, here in New Zealand. The first generation eeePCs were a year ago, but not any more. I shopped around several local computer outlets a month ago looking specifically for a current late-2009 netbook running Linux. Acer AspireOne, Asus eeePC, HP mini. They all said 'sorry, there may be a Linux version available in the States but we only import the Windows one.'
So I bought a Windows one and installed Ubuntu Jaunty Netbook Remix on it - but I was annoyed that I had to bump the Windows stats by one, and pay for a licence I'm not going to use, AND not get an officially supported Linux, to do that.
"Systems with significant feedback are extremely difficult to model usefully. In cases where the model does not converge, it's impossible. THAT's why they don't do it."
However, reality is under no compulsion to care about the ease of computation of your model. And models which are known not to correctly describe reality but are followed anyway are not only not useful, they're actively malicious.
"Any economic model which is computable is not the true economic model" should be either a Zen koan or Murphy's law. Or both. And it should be inscribed on the foreheads of everyone working in finance today.
Oh - right. Rereading the Ultimatum Game, there's a very simple, very obvious way the 1-cent / 99-cent deal is abusive:
If I agree to the 1 cent, I not only get 1 cent *but you gain 99 cents*. That's NOT just money I don't get - it's POWER which goes to you, which you can then use *against* me (ie, you could use it to buy guns, hire armies to directly attack me, or even just build fences to deny me resources)..
But if I veto the deal, the power differential remains unchanged. I might suffer a little because of the immediate lack of resources - but I don't suffer the massive, immediate power loss to you. You don't get to buy any guns or build any fences; I'm 98 whole cents safer.
The choice to me is NOT just 1 cent vs 0 cents - it's -98 cents worth of power differential vs 0 cents of power differential. And that's a very clear, very obvious, very logical choice to make. And it's something completely missed by Austrian school economists, who make the completely unjustified assumption that economic power always and totally represents innocent self-enhancement, rather than social power which can be used against enemies.
The obvious parallel is outsourcing of data centres and 'software as a service'. Shipping my data to your data centre in India might be cheaper than processing it inhouse, so if I take that deal I get free money. Yay! But there's an immediate security cost to me; you now get my data. With that data, you could do any amount of damage to me. How much is the security of you not having my data worth in dollars?
The sense of 'pride' is not illogical in the least - it's all about security and safety in a dangerous world where you can't always trust your economic partners, and where accumulation of money and social power is a double-edged sword which can be turned into either creative wealth or destructive force - *by* rational economic dealers.
The use of force itself can be economically rational, again something Austrian school economics ignores. In a monopoly situation, if I use force against my competitors to eliminate them, I can get higher rents. So a Prisoner's Dilemma type situation emerges in any market where purchasable force (even passive, denial-of-potential-resources force like fences or colonies) is an option.
"if Person A doesn't offer enough to B (say, 20%), Person B tends to reject it, whether out of spite, or a sense of fairness. "
"Most of these financial models, in essence, assume people are Vulcans, when they're not - they're people"
I suspect that even if people *were* Vulcans, they still wouldn't act like Economic Man. The problem with 'thinking on the margin' and always taking that 1 cent regardless of the power differential it sets up, is that Real Life Isn't Like That. Specifically, each economic transaction NEVER exists in a vacuum - which seems to be the main assumption of margin thinking.
Instead, each economic transaction is a single step embedded in a very complex ongoing power game. For example, if I agree to that 1 cent deal, I haven't just made 1 cent I would otherwise have made; I've also given up something in return: I've paid the time and/or resource cost to take part in that transaction, and I've signalled my agreement with your agenda, a signal which may then be broadcast to the group and amplified as future mass behaviour. I've engaged in submission behaviour and established a precedent. In 'emotional' terns, I've lost 'pride' or 'face' - but that's not just an illogical squishy feeling, it's a real matter of social status and trust. The intuitive feeling is that by agreeing to an 'abusive' deal like that, I've somehow squandered my future status and granted my consent to a power differential which could lead to abuse or even ral physical danger; I suspect that this feeling would be mathematically justifiable if we ran the appropriate simulations of group behaviour and resource allocation.
The resource commitment is the most obvious way the 1-cent deal is abusive - in reality transactions are never zero-cost, so there's always an opportunity cost - but there's something else nasty going on, too which is harder to put my finger on. The 'precedent' problem is likely due to the fact that *calculating the cost of decisions* costs nonzero resources, so we tend to make decisions in bundles and as groups - which means that bargaining becomes not just a per-transaction negoatiation, but a matter of dominating the 'choke points' in the decision-making process. Accepting a less-than-fair deal therefore means devaluing future transactions (even by marginal thinking this makes sense, if we assume that all transactions are made based not on *absolute* figures but on changes relative to the current state - again, this probably requires taking into account the fact that every change itself costs resources).
I think there would be a lot of interesting economic science to be done by analysing the mathematics behind our social intuitions. I strongly suspect that something like 'tribal' behaviour will naturally emerge as the most efficient way to make economic decisions, and explain why Austrian school economics is flawed. Assigning a cost to both information and computation (similar to Joseph Stiglitz' research on information assymetry) seems like a good place to start.
"Oh no! Cancer and liver problems! That's sure a lot worse than starvation."
Arguably, yes. Thalidomide babies disturbed people a lot more than mere infant deaths.
As well-informed geeks, I'd like to think we're all well aware of the unexpected population growth side-effects of high-yield hybrid grains.
"GNU doesn't do man pages. 'info' is what you're looking for."
Info isn't what *anyone* is looking for. If they are.... they scare me.
Seconded.
Info is, what, vi for documentation? And I don't use vi for anything else, so I can never remember the weird keystrokes to even exit the thing. If non-man documentation were HTML... heck, even read via lynx/links... that would be sensible.
But no.
"The second reason is that Ubuntu is an unstable distro, which means that the software gets updated a lot, including the kernel. The way ndiswrapper works, is that part of it, is a userland app and another part of it is a kernel modue. The kernel module has to be recompiled every time you upgrade your kernel because of the way ndiswrapper is designed."
That's an explanation, not a solution - and tends to support the parent poster's argument.
It fundamentally IS NOT RELEVANT what technical arguments can be made to support a particular design, if the upshot is that that design DOES NOT DELIVER a functional system.
Where 'functional' in this case means 'the system should at all times work with currently shipping bulk-retail hardware.'
It just doesn't matter what technical reasons may or may not hold why Linux doesn't work with Currently Selling Widget X. If it does not work for User Z with Currently Selling Widget X, then that's a bug and needs to be fixed.
Whether the ultimate solution is social, technical, economic, or leglislative also doesn't matter. The implementation of the fix doesn't matter. The only thing that matters is that User Z can't use Linux to do what she needs it to do. If she can't, she'll buy Windows or OSX instead, because having a working system trumps every other alternative.
"If you run XP on a MacBook or build a 'Hackintosh' you are going to have to be sure you have supported hardware.
Why should anyone expect different from linux? Just because it very often "Just works" on linux doesn't mean it always has to. "
That would be fine if you could get 'certified for Linux' hardware as a Just Works option, like you can for Windows or OS X, and pursue 'hacking your own' as a sideline.
But you generally can't. Even the netbooks that once shipped with customised Linux now aren't available with anything other than Windows. At least here in NZ they aren't. Try getting a new Aspire or eeePC with an official, supported Linux in 2009.
This fundamental lack of hardware support makes Linux an also-ran when you're purchasing at a corporate level.
As a data point, my Quickcam seems to randomly stop working about every second Ubuntu update. I've been running Linux since Red Hat 5, moved to Ubuntu when the Great Fedora Fork happened, used to compile my own sbca driver, and things are *slightly* better now for webcam support than they were ten years ago... but only slightly. Random weird driver breakage between versions just seems to happen and it's a case of shrug and deal with it by Googling forums for several hours and copy-pasting cryptic command lines that you hope are relevant and won't break even more stuff.
Okay, so I can do this. Except I'm getting mighty sick of it. Not sick enough to leave Ubuntu, but still, it's a drag.
Similarly, the Hardy-Intrepid-Jaunty update killed my sound for no good reason other than Ubuntu's upgrade process wasn't smart enough to install the right .debs for full PulseAudio support. Again, no big... as long as I was comfortable wading through techy forum stuff I didn't really understand myself. PulseAudio seems to have so many more dials and knobs and pathways for things to get broken between sound card and application that it's much harder to even begin to understand what might be wrong.
These sort of things might be the price of upgrades, but they still seem to be regressions in overall software quality, and that's worrisome. We're putting more effort than ever into the Linux desktop experience, and sometimes getting LESS than zero improvement.
"2. Incomplete, incomprehensible, multi-format documentation."
Worst offender: "info". Brrr.
Second worst offender: all of the various iterations of the GNOME help browser. No functional search, or none that makes sense.
"Imagine what would happen if someone takes this shit seriously, and gets a descent core.."
A 3D user interface where you have to fly upside down through asteroid tunnel systems rescuing your hostage files, and to shut down you shoot the nuclear reactor?
"If you're a programmer writing programms for other programmers, you want all output and input to be in the form of ASCII or UTF-8 text, so that it is easilly manipulated by other programs"
"With programs written for programmers, the GUI is usually tacked on after the fact just to help users use the program"
While I agree with this assessment, I'd like to dig a little deeper into *why* this is so.
I think the problem is that our current GUI model/metaphor is fundamentally broken (or lacking an important feature). Our GUIs are not expressive enough - they are not as expressive as plain text, nor are they composable like text is. This has been seen as an acceptable tradeoff because GUIs are seen as fundamentally 'for the user', not 'for the programmer'. And this creates the big divide between users and programmers.
But what if the GUI could be made compositionally complete?
It frustrates me that GUI development essentially stagnated right after the Xerox Star created the 'icon' and 'folder' metaphor. That was a good mapping of the hierarchical Unix filesystem onto a 'desktop' visual metaphor - but it did nothing for the rest of the system, it did nothing for processes, or for visually mapping arbitrary code/data. We still had to use text for that.
What if we could reinvent or extend GUIs so that they were precisely as powerful as a text config file or C++ code? Some kind of node-based or list-based or pipe-based visual abstraction which we could then manipulate and especially compose in EXACTLY the same way a programmer would compose Unix batch files?
I'm thinking something like XSLT transformations. Maybe not exactly, but that sort of thing. If the GUI were *just* and only just a view of an underlying (dynamic) data/computation structure.
Then we wouldn't have to choose between 'text' or 'GUI'. It would be simply 'data' and 'view of data'.
Yeah, I know things like progress bars complicate the matter. A GUI-like 'view' of a process is necessarily event-based, interactive and incremental, while a text-like view is usually sequential and deals with whole blocks of data at a time. But I don't think it's fundamentally unthinkable. What if we took, for instance, Unix pipes, and made them streams of *events* represented as text? Then you could pipe a text file or syslog through a filter which generated on the fly an interactive GUI grid-view.
Our current 'but you have to first start a new SVN project, then code an application which creates a dialog box and runs an event loop, then compile it, then link it, then install it into your system, then launch it, then have it read the data from a file...' mentality stops us doing this sort of thing. Which is why I think that workflow has to change. We have to be able to instantiate things like custom dialog boxes completely on the fly, automatically, no compilation required. And there has to be zero data loss, zero impedance mismatch, between computer-processable and interactive representations.
"I think the solution (assuming you want to solve it) is for developers to find ways to solicit feedback from common users, and then address those issues the users find most frustrating."
What about my favourite solution: rearchitecting the framework for developing the software to make it possible for *the users themselves* to contribute small, effective, and safe changes?
I think our current 'best practice methodology' for developing applications - a hard wall between 'developers', who write in raw C/C++/C#/Java and manage nightmare issues like locks and concurrency and threads and buffer overflows, and 'users', who get to click the pretty buttons and go 'aww' at the colours, is all kinds of wrong. Yes, it works, but it dumps all the responsibility for doing everything onto the developer class, who sneer at the user class for being dumb.
Plugins help a bit - at least they allow a third class of 'plugin developer' between 'application developer' and 'end user' - and scripting languages help more - but I think we can, and should, do better. It should be dead easy, and safe, for complete end users to be able to pick up and tweak elements of the 'application' - especially the user interface - that don't work for them, or are irritating. Things like 'the dialog box is too small by five pixels', which have zero algorithmic content, should be so abstracted out of the design loop that a user could literally just click and drag a box and have it rewrite the XUL file, or whatever.
This was the Smalltalk vision, remember? That you could divide programs into 'objects' so that the user could completely - and SAFELY - customise their experience.
Yet it hasn't worked out like that, at all, for Windows OR for Mac or Linux. Doing GUI coding seems to still be horribly, insanely brittle and dangerous, so we don't trust the users to do that. We promote the use of completely different tools, workflows, and even languages for application development vs plugin or script or macro development. And we're back to a hard wall between two classes of user and developer who don't share methodologies or incentives.
But why? I think we need to rethink how we design GUI development frameworks. The current model doesn't seem to be working.
We might still be using steam, but glorification technology has advanced tremendously since the nineteenth century.
Modern glory engines generally achieve virtue ratings in the giga-archangel range on the Baden-Powell scale. The biggest problem is containment of the antikarma halo from contaminating the surrounding noosphere and uplifting our whole cultural discourse; in the worst case, this could create a self-perpetuating virtuous cycle, the so-called Shambala Syndrome. In some cases residents within fifty miles of glory stations have tested positive for elevated morals. There have even been unconfirmed reports of spontaneous canonisation, yet the International Glorification Commission still claims this technology is safe.
It's time to wake up, people. The smoking gun could come in the form of clouds and trumpets.
"No, the programmer can not solve the problem with pen and paper. It requires the hardware that is designed and built by other people. It requires the libraries that are written by others. It requires the electricity that is provided by others. The programmer would die long before he could complete the algorithm on paper and the programmer does not understand all the subsystems required to make the algorithm accurately and proficiently run."
Reread what I said. Hardware isn't required to solve *problems* as problems. Pencil and paper can do it - yes, it might require more than the programmer's lifetime, but that's not a problem since you can always train more programmers to carry on.
Solving well understood problems *in realtime*, and delegating the repetitive solving of such problems to a subsystem, yes, that's a different thing. But it's actually a very narrow subset of intelligence. My claim is that you can't replicate general intelligence by using small mechanical systems geared to do very precise calculations fast. They are fast *because* they are less general.
You're claiming that an AI HAL1, itself unable to solve a certain problem, nevertheless possesses the even more general and more powerful meta-level problem-solving ability to CREATE - conceptualise, design, implement, test and maintain - another AI HAL2 which possesses a problem-solving power HAL1 itself doesn't have.
I'm claiming that not only will prove to be physically impossible - but is in fact logically incoherent.
Libraries and algorithms written by others - okay, now you're talking about a whole different order of problem-solving: trying to get correct output without correct input. Yes, without the correct, relevant algorithms and data, no computer will be able to solve any problem. I believe this realisation is why the 1980s AI wave started to focus on 'knowledge' as the critical factor. But they ran into philosophical problems with representing (and recognising the truth/relevance/validity of ) knowledge which have still not been ironed out yet.
However, a human programmer has an advantage over a computer here: humans are in fact able to infer, guess, intuit and just plain cheat their way to recognising and creating knowledge *without* full and precise algorithms or precisely correct data. That's a capability we still haven't worked out how it works yet.
"In the same way, a team of AI computers, each with their own specialty could design better hardware and software that one AI would not be able to solve by itself."
But a single computer running VMWare could simulate that whole cluster, right?
So it's not that the AI is NOT ABLE to solve the problem by itself. It has the algorithms. It's just that it can't do it *fast* enough.
This is the very assumption that Strategic Computing was labouring under - that we already understood the core basics of 'intelligence' as symbol manipulation / expert systems / knowledge representation / inference, and the only limitation to achieving AI was knowledge base + speed.
Read the book. That turned out to be a very interestingly flawed assumption, and it led directly to the 'AI Winter' of the late 1980s / early 1990s when the DARPA funding dried up.
Bottom line is we don't actually have a very good idea at all about what 'intelligence' is. Not just 'we don't know how to make it fast enough', not just 'we don't know how to program it' but even 'we don't know how to program a computer to RECOGNISE it if it were able to program another computer to program it'.
Yo momma so associative, her Grothendieck group is isomorphic to Z for a bounded complex of finite dimensional vector spaces possessing the standard Euler characteristic.
"Ape B... is lazy, stupid and generally useless.... makes it through life by getting A type apes to do things"
If Ape B is so good at getting Ape A to do things, he's not actually stupid at all. In fact, he's probably socially a lot smarter than Ape A.
Conversely, the mere existence of Ape B shows that Ape A is deficient at organising - otherwise there'd be no niche for B to inhabit.
Moral: social intelligence is not a lesser kind of intelligence than technical intelligence. It's equally powerful and equally useful. And can be abused just as equally
"treatment for the easy and/or obvious stuff has been developed: "
Easy, obvious and affecting well-off Westerners, yes.
Easy, obvious and generating zero revenue for drug companies? Not so much.
"humans can only solve certain mathematical problems by building computers."
There's something missing from that sentence.
"can only solve certain mathematical problems IN A REASONABLE TIME by building computers."
We can solve the problems without computers just fine using a bunch of people in a room, like we did for the Manhattan Project (where women were literally called "computers").
We just don't like to do it that way because it's very slow, and we're impatient. But the computer gives us no results we're not otherwise CAPABLE of generating by applying the calculating rules ourselves.
One of the illusions of the 1980s Strategic Computing AI project was that all that was needed to make strong AI was to vastly speed up computers. We got the speedup - but it didn't get us AI.
This suggests that the "computers can solve problems humans can't because intelligence is a subset of calculation" argument is precisely inverted. Humans can indeed solve problems computers can't. Computers can solve a SUBSET of problems humans can - but they can do that subset much faster and more rigidly.
Intelligence may well be a superset, not a subset, of calculation.
"Somethings are greater than the sum of their parts. eg. emergent behavior, ant society, co-operatives."
That's not true in the way it's usually portrayed.
Emergent behaviour IS THE SUM of its parts, no more, no less. If the individual components do not express the fundamental laws of a system, that system will not display behaviour generated by those laws.
In other words, if HAL2 is a complex of HAL1s, and HAL2 can do something, then HAL1 always did have the capacity to do that too. It just wasn't initially obvious. But obviousness is not the same thing as identity.
Very simple laws are more powerful than you may initially assume - but the emergent system described by those laws is not 'greater' than the laws themselves. Three bodies orbiting in space are not 'greater' than the law of gravity they follow just because their motion is complex and unpredictable.