A BIG problem with switching to Dvorak is most common keyboard shortcuts aren't convenient. Imagine stretching your fingers over the keyboard to do a Ctrl-C Ctrl-V
You've never used Emacs have you?
Alt-W, Ctrl-Y
yes, that's easy to reach. Undo? Why that's simply Ctrl-Shift-minus. Oddly however, once you get used to using the modifier keys these shortcuts seem natural rather than hard to reach. Any keyboard layout is good if you get used to it.
To be frank, not really no. That's a nice XUL frontend to Google's main search page (which is to say, a lonely search box), but fails to carry the XUL through to handling the results, which is where it would actually have been useful.
Besides, Google needs to have its basic search keep its simple spare design for easy access from any number of browsers and to maintain the overall simplicity of basic searching.
GMail, on the other hand, has an interface, and it's an interface that coulc benefit from the rich GUI components provided by XUL.
How about interesting XUL based interfaes for GMail, Froogle, Orkut etc. A simple browser detect determines if you have Firefox/Mozilla, and if you do it gives you the XUL version... if not you get the same ordinary version you get now.
Entirely possible, and could be very cool if done well, but to be honest I see it as unlikely.
Being the first to market (and the name recognition that goes along with it) can be a very powerful ally indeed.
To be fair, this was potentially something that patents were about: If a small company or lone inventor comes up with a stunning new product they potentially don't have the capital to get it to market. To get the capital they need to shop the invention around venture capitalists. Once they've made the idea somewhat public (in the shopping around phase) a large company with lots of resources could easily duplicate, produce, and market said invention before the inventor can manage to raise the capital and get production underway. In principal the patent would help alleviate this because the invention could be openly published, but there would still be a window of time for the inventor to raise funds and get his product to market before anyone else was allowed to join in.
Of course in this day and age of NDAs for everything, and the rate at which new products (particularly software) can be brought to market, this sort of concept just doesn't carry as much weight as it use to.
Ah, yes, the old "don't let them look up logarithms in a table" trick.
But it's true! Your used to be allowed to request a copy of Eton tables in math exams, and be provided with one. The last time I asked a proctor for a copy they just looked at me completely blankly as if they'd never heard of it.
I also recall a "Formula for Murphy's Law", and a "Formula for the Perfect Joke", but the quick search didn't turn those up.
It wouldn't be so bad if they didn't present the things so earnestly. And besides, as a joke the whole concept is long since lost any semblance of interest or humour.
About the only formula of value the BBC seems to have turned up in all this is "The Formula for Pumping out Online Content", and the "value" of that one is highly dubious as it is.
Why does the BBC continue to publish this drivel? This is about the 5th article where some git has come up with a "mathematical formula" for something which is complete drivel.
First it was "the perfect joke", then "the perfect horror movie", and "the perfect family game", then I think we had "murphy's law". Every time it's just a bunch of random subjective factors strung together into (usually linear) formula that's realistically as arbitrary and subjective various factors they're combining.
Yes, yes, all fun and amusing and all that. Well, it was the first time - a bit of a laugh. The second time it just seemed a little silly and pointless. By this point it rates about as funny as a slashdot meme. Why publish this crap?
This was one of the theories exlained to me, years ago in a physics class on how matter transportation may be accomplished...reconstructing by layers.
The downside was you had to be destroyed to find out what you were made of in order to reassemble you.
Don't worry, any research into such things will be rapidly banned in the US I would expect. Anything that involves the construction of a living organism from base matter in anything other than the "church approved" manner is going to find itself in difficulty given the way things are going in the US.
I'm not complaining about the church approved method for constructing organisms of course, I enjoy it myself from time to time, even if the organism construction usually doesn't take. On the other hand, I don't see a problem with trying to figure out how matter and organisms work, and trying for soem artificial (and more consistently reproducible) methods for the same.
Marvel's argument has been that they made no money on the film. All the money made on the film was spent on production or marketing.
Actually its even more cunning than that. Take a read of how studio accounting actually works. It's an endless array of scams to make sure the end result is that practically no film ever makes a profit... for accounting purposes anyway.
An example, from the link, is how they organise accounting of profits from Video (which includes DVD these days). In the old days when video was new independent video distributors payed a flat 20% of revenue to the studio for the right to produce market and sell the videos. Now the studios all have their own video distributors, and the video marketing is simply an arm of the studios full marketing division. Oddly, for accounting purposes the "profits" the studio makes from all video and DVD sales is still recorded as a flat 20% of video revenue. Whatever profits the independent distributors used to make while paying 20% to the studio (probably more because the studio already has marketing etc. integrated in) now happily goes to the studio as profit that never gets recorded in the official net return for the film!.
Such accounting tricks (or flat fraud if you're honest) is carried out in all manner of diffeent areas nibbling more and more off the final "profit" earned by the film till it amounts to a net loss. Read the link. It's frightening.
Concidernig the huge trade deficit the US is facing, I think that wat the grandparent said, might very well be true. The euro might lose value to other currencies (like the yen), but it is very unlikely (not impossible though) that the confidence in the US (that's one of the main reasons the USD has had such a high value) will stay the same. Once people will start using the euro as a "standard", confidence in the USD will fall and it will keep losing value.
It is still quite uncertain as to how things will pan out, and acceptance of the Euro as a global currency is not certain either. However, there are very real risks here for the US, especially if any correction to the US Dollar is rapid, be it caused by the current account deficit, the Euro becoming a global currency, or the US simply becoming less competitive on global markets as China, India and the like improve. I've written about this in depth, you can find the link to a version in my sig, or you can find the same essay on Kuro5hin, FreeRepublic, or DemocraticUnderground.
In short, I think we'll see a BeOS come-back long before an Amiga come-back.
Well this looks at least as nice as Amiga OS4, has far more software available for it (the GoBe Productive suite runs fine for instance), and runs on standard PC Hardware. So yes, the BeOS come-back is already ahead of the Amiga come-back.
Actually, it's more of a use of XML as a source code translator from one language to another.
Actually, that's what it's not, because it's not very good at that. See my post here as to why. Translating between languages is hard because translating between languages is hard. XML doesn't magically make the difficulties go away.
But all other current computer languages have a pared-down, poor text representation of math notation -- why shouldn't an IDE be able to render that as nicely-formatted, WYSIWYG, directly-editable formulas? There's no particular reason they can't, really.
You realise that mathematicians, the people who spend far more time writing far more math formulas than any programmer, don't use WYSIWYG tools for writing and editing formulas because it is a pain in the ass. There is a reason that LaTeX is the way to write math: despite a small learning curve it's the fastest most efficient way to write math (with any standard keyboard anyway).
I guess I mean binary code compiled to a particular machine's architecture. That executable code simply won't run in a foreign environment. But XML is XML is XML. Java and the idea of a virtaul processor or virtual machine is another attempt at "silver bullet" cross compatibility, and another not-so silver bullet.
This XML idea is essentially just recreating Java bytecode with the disadvantage of being incredibly verbose and bloated and not actually executable, and the minor gain that it is easily decompilable.
I don't really know, not being a Java guru, but how good are the Java de-compilers if any?
Language conversion. Say you find some open source Perl code that does exactly what you want, but you are a Java shop. So, just run the XML version of the code through an XSLT and voila!
Lovely theory, but I'd like to see you pull that off in practice. What if I start using some very idiomatic language paradigms in perl, which all make good sense there, but result in, at best a tangled barely intelligible mess of Java, at worst something unconvertible. What this does, in effect, is reduce every language down to a poor quality "lowest common denominator". How do you easily convert a functional language into a procedural one? How do you convert you OO Java code into C? Sure, it can be done, but itf its done in an automated way I'm not sure I would want to be the one responsible for editing and maintaining the results.
That is a good idea. And I can think of many other similiar features you might want for an editor / project development system. However I doubt XML will end up being the best solution. I would guess that the best solution would be a custom file format that was desgined for this reason.
Brilliant idea. Let's start by just using parentheses for delimiters instead of all that stuff, and just have the first word inside the parentheses define the operation, and the other (space delimited, why not?) words simply be the list of arguments to be processed. That sounds nifty. Now lets take that example from the article and convert it into this condensed format...
If I'm wrong, then this might be slightly more interesting in the long run than, say, Cyclone, where you have to learn a tiny amount more of additional syntax to mark that "this pointer was meant to point to data, not code", "this pointer should not write beyond this boundary", "this function has no business mucking up its stack", etc.
Out of curiousity, does Cyclone differ greatly in effect from, say, Eiffel, or any of the myriad of Design by Contract extensions you can get for Java, Python, and who knows what else? I always liked the look of Design by Contract, but didn't much care for the look of Eiffel... and I'm still waiting for the Python Design by Contract proposal (which is actually quite nice!) to get accepted into the mainstream.
I just skimmed the article a bit, but I believe the idea is that you write your code the way you want to but the code is translated into the xml format and stored that way. When you reopen it, it's translated back into your preferred syntax.
So what we're really talking about is something like Microsofts CLR, Java's bytecode, or Parrot code, with the ability to de-compile it back into the language of your choice? We just get the added bonus that the "compiled" code is not actually compiled, and is stored in the most padded verbose unreadable format that could reasonably be arranged? Doesn't sound like a vast improvement.
What Windows apps would Novell be porting over to Linux exactly? You want all the other companies that develop for Windows to port their stuff to Linux... which isn't going to happen unless Linux gets a little more desktop marketshare. Evolution on Windows is another step in providing an easy migration path. It makes groupware available as something that can be slowly migrated over.
I am presuming that your complaint would be that if they already have Evolution on Windows why would they switch to Linux? Perhaps because, as nice as Evolution might be on Windows, the Windows version of Evolution is never going to be as fast, as nice and as integrated as it is on Linux - where it fits in elegantly as part of GNOME.
I've seen a migration go almost exactly like that: they started with Windows versions of one or two Linux apps, added a few more, and then a few more, and found themselves wondering why exactly they weren't just running Linux where all these applications came preinstalled into their native environment by default. Migration to Linux (at least for that segment of the company) followed shortly after.
Evolution, in combination with the likes of OpenOffice.org, Firefox, and all the other bits and pieces can very effectively spark a similar migration on a wider scale as it provides migration apps for a much wider array of users.
I guess the inability to discern between buzzwords and features extends, beyond marketers and purchasers, to the writer of the article.
But that'd precisely the problem! Yes, indeed "scalable" has a well defined meaning with regard to software. The problem is that the word has been attached so widely to so many things where it is hardly relevant, simply because it is the buzzword of the moment, that it has lost its meaning. It is entirely possible now to see a product that marketing materials describe as "scalable" and yet have no idea how "scalable" applies to the product in question. The word has, within marketing circles, been stripped of its meaning. That is of serious concern.
Personally I just LaTeX for presentations. A little familiarity with it makes it quite easy to write your own presentation document class that looks every bit as nice as a powerpoint presentation. The only thing you lack is slide transition effects which, to be honest, I've never had a need for in mathematics presentations.
I have a slew of applications that are either just a stand alone executable, or a stand alone executable with some supporting data files in the directory.
Yup, it's called static linking, and it's actually not all that good. Linux could do it, but made a chocie not to go that route - open source went the hard way and ended up with lots of dependencies. That has meant solutions have been slower (we're still waiting on solutions for third party apps, but they're coming), but it will be worth the effort.
Statically linking so that your binary is self contained means:
(a) You are wasting RAM as each binary loads its own version of all the commonly used libraries.
(b) Your security is poor. If some commonly used library gets compromised you have to update every single application that linked against it - which could be a large number indeed. If it's all dynamically linked (with dependencies) you update the library, and all the apps just automtically use the patched version.
You're not going to get statically linked binaries, as it's just a dumb idea all around. What you will get is solutions like RPM, dpkg, apt, apt-rpm, yum, portage, zero-intstall and autopackage which will make installation as easy as you seem to want it to be - you'e just going to have to wait another year or three for the final few pieces to slot into place and the user friendliness to fully kick in.
Because they haven't yet done the work necessary to support installation on non-Debian-based distros. However, the concept is sound and the implementation is straightforward. All that is needed is to compile a list of common base software that should be available on every distro.
Welcome to "The Problem". How do you know what's installed, and which version it is? If it's Debian it's easy because it's all standardised, if its any distribution then it gets very hard very fast (particularly on version of library etc). You have to figure out whether the library is there even though the location, name, and version may all be different. Drawing up a huge table for every distribution out there is going to be very tedious indeed. Especially when you need a seperate table for each library dependency. The instructions for making klik work on SuSE get around this by literally making you copy over the libraries from a working Debian distribution. It's quite a list to copy over to make everything work.
So you're down to 2 choices - have an unbelievably complex bunch of logic to check what distribution it is, what version of the distribution that is, determine what the corresponding locations and names of the required libraries are, checking if they're installed and what version they are etc. or simply packaging up all the required shared libraries into the package - which is to say, ignoring dependencies entirely... which raises all sorts of other issues like RAM use, and security.
Making this portable across distributions is incredibly hard. It's not the easy last step. If you want portable across distributions try Zero Install or something. I doubt it'll happen all that soon with klik.
The autopackage stuff also will know nothing of Debian policy. Hence, it will suffer from exactly the same problems. The policies define the packaging environment, not the files or the tools. Third-party installation on Debian is also simple. Just use epkg, stow, whatever in/usr/local. No, it won't know about Debian dependency policies. Neither does autopackage.
So the easy way of installing third party packages on Debian is to compile it from source? That being what stow (which I use), and from the look of it epkg, require you to do. You my as well use checkinstall instead, it'll provide more useful results (it adds a source compiled program into the dpkg database). No, that oesn't sound like the easy solution to let Grandma install third party packages that the original poster I replied to was looking for.
Let me quote the original again:
There is just one area where linux does have a problem when it comes to installing programs and that's when the program is not provided by the distribution.
The issue is when the program is not provided by the distribution: right now that's not easy, or so the OP claimed. Your solution is: compile it from source and use stow or epkg to put it somewhere nice. That's not a solution, that's what we've had for the past 5 or more years on any distribution. If that was a solution why do you think people keep raising the issue as a problem?
To be honest I have no idea quite what you're ranting about any more. The question was: "Will this make installing non-distro provided packages easy at last?", my answer was "no, as good as klik is, it only really works with Debian based distros, so is just more Debian packaging really. Try autopackage if you want to install 3rd party apps."
You seem to have taken great offense, but I'm not sure to what.
Slashdot Mirror
A BIG problem with switching to Dvorak is most common keyboard shortcuts aren't convenient. Imagine stretching your fingers over the keyboard to do a Ctrl-C Ctrl-V
You've never used Emacs have you?
Alt-W, Ctrl-Y
yes, that's easy to reach. Undo? Why that's simply Ctrl-Shift-minus. Oddly however, once you get used to using the modifier keys these shortcuts seem natural rather than hard to reach. Any keyboard layout is good if you get used to it.
Jedidiah.
To be frank, not really no. That's a nice XUL frontend to Google's main search page (which is to say, a lonely search box), but fails to carry the XUL through to handling the results, which is where it would actually have been useful.
Besides, Google needs to have its basic search keep its simple spare design for easy access from any number of browsers and to maintain the overall simplicity of basic searching.
GMail, on the other hand, has an interface, and it's an interface that coulc benefit from the rich GUI components provided by XUL.
Jedidiah.
How about interesting XUL based interfaes for GMail, Froogle, Orkut etc. A simple browser detect determines if you have Firefox/Mozilla, and if you do it gives you the XUL version... if not you get the same ordinary version you get now.
Entirely possible, and could be very cool if done well, but to be honest I see it as unlikely.
Jedidiah.
Being the first to market (and the name recognition that goes along with it) can be a very powerful ally indeed.
To be fair, this was potentially something that patents were about: If a small company or lone inventor comes up with a stunning new product they potentially don't have the capital to get it to market. To get the capital they need to shop the invention around venture capitalists. Once they've made the idea somewhat public (in the shopping around phase) a large company with lots of resources could easily duplicate, produce, and market said invention before the inventor can manage to raise the capital and get production underway. In principal the patent would help alleviate this because the invention could be openly published, but there would still be a window of time for the inventor to raise funds and get his product to market before anyone else was allowed to join in.
Of course in this day and age of NDAs for everything, and the rate at which new products (particularly software) can be brought to market, this sort of concept just doesn't carry as much weight as it use to.
Jedidiah.
Ah, yes, the old "don't let them look up logarithms in a table" trick.
But it's true! Your used to be allowed to request a copy of Eton tables in math exams, and be provided with one. The last time I asked a proctor for a copy they just looked at me completely blankly as if they'd never heard of it.
Jedidiah.
Crazy Brits. How are all the variables expressed in a numerical value? This is just plain stupid, IMHO.
This is just one in a string of such crap from the BBC. With a quick search I found "The Perfect Horror Film", "The Perfect Film", "The Formula for Happiness", "The Formula for On Screen Chemistry", "The Formula for the Perfect Family Christmas".
I also recall a "Formula for Murphy's Law", and a "Formula for the Perfect Joke", but the quick search didn't turn those up.
It wouldn't be so bad if they didn't present the things so earnestly. And besides, as a joke the whole concept is long since lost any semblance of interest or humour.
About the only formula of value the BBC seems to have turned up in all this is "The Formula for Pumping out Online Content", and the "value" of that one is highly dubious as it is.
Jedidiah.
Why does the BBC continue to publish this drivel? This is about the 5th article where some git has come up with a "mathematical formula" for something which is complete drivel.
First it was "the perfect joke", then "the perfect horror movie", and "the perfect family game", then I think we had "murphy's law". Every time it's just a bunch of random subjective factors strung together into (usually linear) formula that's realistically as arbitrary and subjective various factors they're combining.
Yes, yes, all fun and amusing and all that. Well, it was the first time - a bit of a laugh. The second time it just seemed a little silly and pointless. By this point it rates about as funny as a slashdot meme. Why publish this crap?
Jedidiah.
This was one of the theories exlained to me, years ago in a physics class on how matter transportation may be accomplished...reconstructing by layers.
The downside was you had to be destroyed to find out what you were made of in order to reassemble you.
Don't worry, any research into such things will be rapidly banned in the US I would expect. Anything that involves the construction of a living organism from base matter in anything other than the "church approved" manner is going to find itself in difficulty given the way things are going in the US.
I'm not complaining about the church approved method for constructing organisms of course, I enjoy it myself from time to time, even if the organism construction usually doesn't take. On the other hand, I don't see a problem with trying to figure out how matter and organisms work, and trying for soem artificial (and more consistently reproducible) methods for the same.
Jedidiah.
Marvel's argument has been that they made no money on the film. All the money made on the film was spent on production or marketing.
Actually its even more cunning than that. Take a read of how studio accounting actually works. It's an endless array of scams to make sure the end result is that practically no film ever makes a profit... for accounting purposes anyway.
An example, from the link, is how they organise accounting of profits from Video (which includes DVD these days). In the old days when video was new independent video distributors payed a flat 20% of revenue to the studio for the right to produce market and sell the videos. Now the studios all have their own video distributors, and the video marketing is simply an arm of the studios full marketing division. Oddly, for accounting purposes the "profits" the studio makes from all video and DVD sales is still recorded as a flat 20% of video revenue. Whatever profits the independent distributors used to make while paying 20% to the studio (probably more because the studio already has marketing etc. integrated in) now happily goes to the studio as profit that never gets recorded in the official net return for the film!.
Such accounting tricks (or flat fraud if you're honest) is carried out in all manner of diffeent areas nibbling more and more off the final "profit" earned by the film till it amounts to a net loss. Read the link. It's frightening.
Jedidiah.
If the US Dollar declines fast, which it may if things move into a selling panic, it could be very very bad for the US. See my sig.
Jedidiah.
Concidernig the huge trade deficit the US is facing, I think that wat the grandparent said, might very well be true. The euro might lose value to other currencies (like the yen), but it is very unlikely (not impossible though) that the confidence in the US (that's one of the main reasons the USD has had such a high value) will stay the same. Once people will start using the euro as a "standard", confidence in the USD will fall and it will keep losing value.
It is still quite uncertain as to how things will pan out, and acceptance of the Euro as a global currency is not certain either. However, there are very real risks here for the US, especially if any correction to the US Dollar is rapid, be it caused by the current account deficit, the Euro becoming a global currency, or the US simply becoming less competitive on global markets as China, India and the like improve. I've written about this in depth, you can find the link to a version in my sig, or you can find the same essay on Kuro5hin, FreeRepublic, or DemocraticUnderground.
Jedidiah.
In short, I think we'll see a BeOS come-back long before an Amiga come-back.
Well this looks at least as nice as Amiga OS4, has far more software available for it (the GoBe Productive suite runs fine for instance), and runs on standard PC Hardware. So yes, the BeOS come-back is already ahead of the Amiga come-back.
Jedidiah.
Actually, it's more of a use of XML as a source code translator from one language to another.
Actually, that's what it's not, because it's not very good at that. See my post here as to why. Translating between languages is hard because translating between languages is hard. XML doesn't magically make the difficulties go away.
Jedidiah.
But all other current computer languages have a pared-down, poor text representation of math notation -- why shouldn't an IDE be able to render that as nicely-formatted, WYSIWYG, directly-editable formulas? There's no particular reason they can't, really.
You realise that mathematicians, the people who spend far more time writing far more math formulas than any programmer, don't use WYSIWYG tools for writing and editing formulas because it is a pain in the ass. There is a reason that LaTeX is the way to write math: despite a small learning curve it's the fastest most efficient way to write math (with any standard keyboard anyway).
Jedidiah.
I guess I mean binary code compiled to a particular machine's architecture. That executable code simply won't run in a foreign environment. But XML is XML is XML. Java and the idea of a virtaul processor or virtual machine is another attempt at "silver bullet" cross compatibility, and another not-so silver bullet.
This XML idea is essentially just recreating Java bytecode with the disadvantage of being incredibly verbose and bloated and not actually executable, and the minor gain that it is easily decompilable.
I don't really know, not being a Java guru, but how good are the Java de-compilers if any?
Jedidiah.
Language conversion. Say you find some open source Perl code that does exactly what you want, but you are a Java shop. So, just run the XML version of the code through an XSLT and voila!
Lovely theory, but I'd like to see you pull that off in practice. What if I start using some very idiomatic language paradigms in perl, which all make good sense there, but result in, at best a tangled barely intelligible mess of Java, at worst something unconvertible. What this does, in effect, is reduce every language down to a poor quality "lowest common denominator". How do you easily convert a functional language into a procedural one? How do you convert you OO Java code into C? Sure, it can be done, but itf its done in an automated way I'm not sure I would want to be the one responsible for editing and maintaining the results.
Jedidiah.
Brilliant idea. Let's start by just using parentheses for delimiters instead of all that stuff, and just have the first word inside the parentheses define the operation, and the other (space delimited, why not?) words simply be the list of arguments to be processed. That sounds nifty. Now lets take that example from the article and convert it into this condensed format...becomes something likeHmm, that looks oddly familiar... if we just changed a few of the keywords a litte.. I wonder if someone has thought of something like this before...
Jedidiah
If I'm wrong, then this might be slightly more interesting in the long run than, say, Cyclone, where you have to learn a tiny amount more of additional syntax to mark that "this pointer was meant to point to data, not code", "this pointer should not write beyond this boundary", "this function has no business mucking up its stack", etc.
Out of curiousity, does Cyclone differ greatly in effect from, say, Eiffel, or any of the myriad of Design by Contract extensions you can get for Java, Python, and who knows what else? I always liked the look of Design by Contract, but didn't much care for the look of Eiffel... and I'm still waiting for the Python Design by Contract proposal (which is actually quite nice!) to get accepted into the mainstream.
Jedidiah.
I just skimmed the article a bit, but I believe the idea is that you write your code the way you want to but the code is translated into the xml format and stored that way. When you reopen it, it's translated back into your preferred syntax.
So what we're really talking about is something like Microsofts CLR, Java's bytecode, or Parrot code, with the ability to de-compile it back into the language of your choice? We just get the added bonus that the "compiled" code is not actually compiled, and is stored in the most padded verbose unreadable format that could reasonably be arranged? Doesn't sound like a vast improvement.
Jedidiah.
What Windows apps would Novell be porting over to Linux exactly? You want all the other companies that develop for Windows to port their stuff to Linux... which isn't going to happen unless Linux gets a little more desktop marketshare. Evolution on Windows is another step in providing an easy migration path. It makes groupware available as something that can be slowly migrated over.
I am presuming that your complaint would be that if they already have Evolution on Windows why would they switch to Linux? Perhaps because, as nice as Evolution might be on Windows, the Windows version of Evolution is never going to be as fast, as nice and as integrated as it is on Linux - where it fits in elegantly as part of GNOME.
I've seen a migration go almost exactly like that: they started with Windows versions of one or two Linux apps, added a few more, and then a few more, and found themselves wondering why exactly they weren't just running Linux where all these applications came preinstalled into their native environment by default. Migration to Linux (at least for that segment of the company) followed shortly after.
Evolution, in combination with the likes of OpenOffice.org, Firefox, and all the other bits and pieces can very effectively spark a similar migration on a wider scale as it provides migration apps for a much wider array of users.
Jedidiah.
Jedidiah.
I guess the inability to discern between buzzwords and features extends, beyond marketers and purchasers, to the writer of the article.
But that'd precisely the problem! Yes, indeed "scalable" has a well defined meaning with regard to software. The problem is that the word has been attached so widely to so many things where it is hardly relevant, simply because it is the buzzword of the moment, that it has lost its meaning. It is entirely possible now to see a product that marketing materials describe as "scalable" and yet have no idea how "scalable" applies to the product in question. The word has, within marketing circles, been stripped of its meaning. That is of serious concern.
Jedidiah.
Personally I just LaTeX for presentations. A little familiarity with it makes it quite easy to write your own presentation document class that looks every bit as nice as a powerpoint presentation. The only thing you lack is slide transition effects which, to be honest, I've never had a need for in mathematics presentations.
Jedidiah.
I have a slew of applications that are either just a stand alone executable, or a stand alone executable with some supporting data files in the directory.
Yup, it's called static linking, and it's actually not all that good. Linux could do it, but made a chocie not to go that route - open source went the hard way and ended up with lots of dependencies. That has meant solutions have been slower (we're still waiting on solutions for third party apps, but they're coming), but it will be worth the effort.
Statically linking so that your binary is self contained means:
(a) You are wasting RAM as each binary loads its own version of all the commonly used libraries.
(b) Your security is poor. If some commonly used library gets compromised you have to update every single application that linked against it - which could be a large number indeed. If it's all dynamically linked (with dependencies) you update the library, and all the apps just automtically use the patched version.
You're not going to get statically linked binaries, as it's just a dumb idea all around. What you will get is solutions like RPM, dpkg, apt, apt-rpm, yum, portage, zero-intstall and autopackage which will make installation as easy as you seem to want it to be - you'e just going to have to wait another year or three for the final few pieces to slot into place and the user friendliness to fully kick in.
Jedidiah.
Because they haven't yet done the work necessary to support installation on non-Debian-based distros. However, the concept is sound and the implementation is straightforward. All that is needed is to compile a list of common base software that should be available on every distro.
Welcome to "The Problem". How do you know what's installed, and which version it is? If it's Debian it's easy because it's all standardised, if its any distribution then it gets very hard very fast (particularly on version of library etc). You have to figure out whether the library is there even though the location, name, and version may all be different. Drawing up a huge table for every distribution out there is going to be very tedious indeed. Especially when you need a seperate table for each library dependency. The instructions for making klik work on SuSE get around this by literally making you copy over the libraries from a working Debian distribution. It's quite a list to copy over to make everything work.
So you're down to 2 choices - have an unbelievably complex bunch of logic to check what distribution it is, what version of the distribution that is, determine what the corresponding locations and names of the required libraries are, checking if they're installed and what version they are etc. or simply packaging up all the required shared libraries into the package - which is to say, ignoring dependencies entirely... which raises all sorts of other issues like RAM use, and security.
Making this portable across distributions is incredibly hard. It's not the easy last step. If you want portable across distributions try Zero Install or something. I doubt it'll happen all that soon with klik.
Jedidiah.
The autopackage stuff also will know nothing of Debian policy. Hence, it will suffer from exactly the same problems. The policies define the packaging environment, not the files or the tools. Third-party installation on Debian is also simple. Just use epkg, stow, whatever in /usr/local. No, it won't know about Debian dependency policies. Neither does autopackage.
So the easy way of installing third party packages on Debian is to compile it from source? That being what stow (which I use), and from the look of it epkg, require you to do. You my as well use checkinstall instead, it'll provide more useful results (it adds a source compiled program into the dpkg database). No, that oesn't sound like the easy solution to let Grandma install third party packages that the original poster I replied to was looking for.
Let me quote the original again:
There is just one area where linux does have a problem when it comes to installing programs and that's when the program is not provided by the distribution.
The issue is when the program is not provided by the distribution: right now that's not easy, or so the OP claimed. Your solution is: compile it from source and use stow or epkg to put it somewhere nice. That's not a solution, that's what we've had for the past 5 or more years on any distribution. If that was a solution why do you think people keep raising the issue as a problem?
To be honest I have no idea quite what you're ranting about any more. The question was: "Will this make installing non-distro provided packages easy at last?", my answer was "no, as good as klik is, it only really works with Debian based distros, so is just more Debian packaging really. Try autopackage if you want to install 3rd party apps."
You seem to have taken great offense, but I'm not sure to what.
Jedidiah.