I dont. Color displays correctly, thats all I care about.
Just because you don't use it or don't understand why it's useful does not mean that others can't/wont benefit from it.
Thats something else X does better then Windows or MacOS, it allows you to use different font engine servers, over a network even.
Oh my oh my, this is a stunningly ignorant comment. The advantage of font management under MacOS and Windows, that you seem unable to grok, is the fact that WYSIWYG printing is actually possible. That is, if you can display a font, you can also print it with the same methods. This is simply not true on Linux. ( QT tries to do this, but unsuccesfully. It tries to guess printer font names from the screen font names, but this is very hit and miss, and requires the user to configure their ghostscript fontmap or their printer / PPD ) In general, you cannot print fonts for a few reasons -- some of the fonts are bitmaps, which cannot be scaled to printer resolutions. There are more problems though -- X does not give the developer a way of retrieving outline files and metrics for the fonts. By the time font data reaches the X client, its already simply bitmap data. This means that there is no way for a developer to print screen fonts reliably. In case it's not blatantly obvious at this stage, let me inform you that this means that in general, WYSIWYG printing is nontrivial and involves a lot of ugly kludges. Applixware, Star Office, and Abiword all resort to ugly kludges to handle fonts. It appears that Koffice, which seems to use QTs font handling functions simply cannot print reliably.
Where's the unified print/display model? Its called PostScript....
No, this is not built into the display, at least not in older XFree86 releases. Consequently, it's not built into the toolkits. You've obviously never tried to program any WYSIWYG apps, because if you did, you'd understand how trivial WYSIWYG printing isn't. Tell me this -- how do you write a program, using just the X APIs, that displays a font, and prints that same font ? Once you can do this, you can come back and talk to us about "unified print/display models".
They seem quite usable to me and many other people, who are you to say they aren't?
Again this stupid and childish attitude. You're telling users that if they want these features, they're idiots and they should go away. But who are you to say this ? Are you a developer ? ( it doesn't sound like you understand any of the issues regarding developing GUI apps on UNIX, quite frankly )
Well, that's really nice. Unfortunately, it's also not terribly useful until X ( in particular the X font server ) supports antialiasing, because most GUI toolkits use a font model that sits on top of the X11 font APIs.
Well there doesnt seem to be any reason to "update" it, because that really isnt broke, so why fix a problem that isnt there?
It's a good thing other Linux developers don't have your attitude otherwise we'd still be in caves. X certainly could use DPS ( which is fortunately being added, probably much to your disgust )
Re:Windows forces costly upgrades for home users.
on
Making Linux Beautiful
·
· Score: 2
I beg to differ. Windows forces people to upgrade to the latest software, which costs a fortune for a home user.
The fact is that most users upgrade their hardware faster than they upgrade their OS. Anyone who's bought a computer in the last 3 years most probably had Win95 preloaded. And any computer over 3 years old has depreciated so much that it's difficult to give away.
In the free software world, change is more incremental. 1994 versions of Linux can run the latest software.
If you count libc as part of "Linux", then that's simply not true. libc has gone through 2 major changes. To have any chance of running the latest binaries, you'll need a new distribution.
And above all, if your mum did need a new version of Linux, perhaps to use that new printer she just bought, she could get it for free.
If the printer works with Linux, it will also work with Windows 3.1
It's horrible. Most nice-looking GUI apps now require you to be running Gnome or KDE,
What do you mean by running GNOME or KDE ? It's true that you need the shared libraries installed. To run Motif apps, you need Motif installed, to run Tk apps, you need Tk installed. To run KDE/QT apps, you need the KDE API ( kdelibs and kdesupport ) and QT installed. You do not need to run a KDE/GNOME panel/window manager etc.
There must be a root menu in the lower left corner There must be a task list along the bottom edge of the screen There must be an X in the upper right to close the window
No. You are confusing the desktop environment itself with the APIs. KDE/GNOME are two things. They are a set of APIs and they are "desktop environments". Running KDE/GNOME apps requires only that you have those APIs installed.
Hi Wes. I don't think building it directly into GTK would be the right thing either. Any font handling system would have to be implemented in a seperate API ( for example, freetype ), and then (insert-your-favourite-toolkit) could use that. As for "bloat", many of the kinds of applications that would need this functionality , like office suites, are already so horrendously bloated that perhaps it would not make that much difference.
I think this needs to be implemented somewhere though. Making X antialias is difficult because this would require modifying the way X works ( and would cause possible compatibility problems ).
BTW, antialiasing is only half of the problem. The other problem is the fact that outline files and font metrics are unavailable through the X APIs. This is essential for WYSIWYG printing, because at present, all one can do is grab bitmaps from the X server, but to print, you need the outline files associated to the fonts ( unless you're content to print at screen resolutions ), or you need to know the printer name of the font and have an entry for your font in the ghostscript Fontmap.
Yep, true type fonts are supported ( READ THE RELEASE NOTES ). In fact in Redhat, this is true as of 6.0, with the xfs server shipping with xfsft patches. However, it won't antialias just yet.
You are right about the way Xfonts work. There are some ways this can be addressed with technologies such as Display Postscript. IMO, the best way to handle this is bypass the X font handling model altogether and write an improved font management model into the toolkits. The "improved" model should include functionality to make outline files available ( if they are available ). This is what display postscript does. There is already the technology in place to antialias both type1 and truetype fonts ( freetype ), the problem is all in the X font system.
Koffice's ( in particular KWord's ) printing mechanism is broken enough that it is not usable by ordinary users. The problem is that Koffice has no systematic way of mapping screen fonts to font files ( which means it probably isn't using the font metrics ). Instead, it tries to guess the printer font name from the XFLD ( that cryptic string that looks something like -monotype-arial-medium-r-normal--0-0-0-0-p-0-iso88 59-1 ) The end result is that sometimes, your fonts print right and sometimes they don't. Of course, there is a way around this: You simply work out what names Koffice is guessing for the fonts, and add the appropriate mappings to your ghostscript Fontmap /KWord_Font_name/Correct_font_name;
However, they really do IMO need to do something about the screenprint font mapping problem. In fact, IMO one of the main things Linux needs right now is a standard way of providing the developers with the means to grab a shape file ( if there is one available ) from a screen font name.
I didn't say anything about "too stupid". My point is that it doesn't take very much effort to write a HOWTO ( or rather, the real effort is in writing content, not learning the markup language as you suggest. I should know -- I have written a HOWTO ). The intelligence requirements are not just "low", they are as low as they could be. There are GUI authoring tools, and there's a simple markup language one can use by hand. I don't see how you propose to make it easier. As I said, read the (short) HOWTO-HOWTO, or just use Lyx, and you'll be up and running.
BTW, they are not "crying" for authors, and they are not so desperate for authors that they are willing to accomodate to laziness. As much as making it easy is good, you have to understand that HOWTOs don't write themselves, it does actually involve some effort on the part of the author. I'll say it again, the technical skills requirements for writing HOWTOs are minimal. The real work is in writing the content.
And you didn't answer my question -- what format do you propose as an alternative to Linuxdoc ?
GLIBC upgrading ? -- Forget it ! LDP to the rescue ? -- Forget it ! WHY ? -- COMMERCIAL INTEREST.
Wrong, buddy. Upgrading glibc is plain difficult, because it requires upgrading everything that links to it which is basically every dynamically linked program on your system. The only sensible way to "upgrade" is leave your old libc there and run a hybrid install, but this is difficult, and has a lot of technical difficulties, none of which are Redhat's fault.
If RatHead would make it easy, there would be an RPM to upgrade your libc.
THere is. It's called glibc. The problem is that you also need to upgrade every single application at the same time to a version that is built against the new upgraded glibc.
If you compile all the applications in a distribution in a way that they need the libc at runtime, you would have to recompile every app you use.
Exactly.
and YES, it IS the best way to handle programs, but it's also the best way to force someone to reinstall everything again (read: BUY AGAIN).
Get a grip, buddy. Linux is free ! And CDs are available for next to nothing. Hell, you can probably get someone in your Linux users group to burn you one. My group are always giving out CDs.
SOLUTION: Let the customer who buys a distribution decide whether to trade upgradabiltiy (nice word, hey?) for small apps, with better, overall performance (unless RAM is not an issue and your CPU is fast enough). Let him have the choice to have bigger programs (not dynamically linked) and the chance to upgrade the ESSENTIAL libc. I don't see this happen in my lifetime.
There is little demand for apps statically linked to libc , because most users don't want to load one copy of libc for each process on their system. I have 55 processes running right now. My libc is 4MB. Do the math -- most users don't have this much RAM to burn.
Then please make it easier for authors to contribute. Setting up the whole SGML tool-chain is a major desaster. Having to write in SGML is a desaster, too.
What the hell is a "desaster" ? Anyway, writing in LinuxDoc isn't very hard. Anyone who's written in HTML before can pick it up in minutes. ( "writing in SGML" doesn't make much sense. One writes to an SGML DTD like LinuxDoc, HTML, or Docbook ) For those who can't handle the simple task of learning a simple DTD, there's Lyx ( it'd be good if they'd point to Lyx as an authoring tool )
I am curious as to what format you'd propose over LinuxDoc or Docbook. The requirements are that it should be convertable into several formats, and it should have some logical structure ( so that you can convert it ).
You will not attract a huge bunch of professional technical writers if you don't lower the bar.
I don't like the idea of making the bar too low. I wouldn't want someone who is unwilling to spend a few minutes reading the HOWTO-HOWTO as a HOWTO maintainer ( you know, HOWTOs are not write-only )
I'm the author of the font HOWTO. It appears the PDFs are broken. FYI, here's how I convert to PDF: sgml2latex --output=tex index.sgml sed -e '/\\usepackage{t1enc}/d' \ -e '/\\usepackage{babel}/d' \ -e '/\\usepackage[latin1]/d' \ -e 's/\\usepackage{null}/\\usepackage{null}\\usepacka ge{hyperref}/' \ index.tex > index2.tex mv index2.tex index.tex pdflatex index.tex
This seems to generate good PDF files ( at least with my HOWTO, it does )
Ick...imagine running 400x300 on a standard 19" monitor (most are 18" viewable diag)...this is the resolution we're talking about.
Yes, but you are presumably sitting further from the 38" monitor than the 19 inch. My 19" takes up all except my peripheral vision. If you compare this with other ultra-large ( > 21' ) display monitors, you'llfind it's in the same league resolution-wise
Problem is that you do need calculus to understand the book at least some of the stuff I was seeing.
You hardly need to be a calculus expert to understand what an integral sign means.
Most of the interesting things (unfortunately) have a shit load of math behind them.
I did calc in high school. It hardly constitutes a "shitload" of math. You're right that a lot of things need basic math. It's got nothing to do with "elitism" or "keeping the rabble out", or "keeping it expensive" -- I don't know about you but my high school education was free. It's got to do with the fact that the moment you start doing anything quantitative or analytical, you inevitably need some math. In other words, real scientists need to know some math. The fact that you can throw together some code does not make you a computer scientist.
Capitialism existed very well without the concept of intellectual property until the 1800's.
Well IMO, capitalism really didn't "exist very well" prior to the 1800's. Most capitalist societies of those days were barbaric by todays standards. There was no notion of a "publically held" company ( they were just moving towards that around 1800 ).
Moreover, there were many differences between the 1800s and nowadays. Piracy is much easier now than it was then. It was much less of a problem in the 1800s, since duplicating media was not very easy until quite recently ( try burning an LP on your hi fi system some time... )
You are assuming that intellectual property is a valid form of property. Not every one accepts this,
Not everyone even accepts that there exists a valid form of property. Those who believe exclusively in weaker notions of "property" are still anti-property, but less so than those who don't acknowledge any concept of property.
Intellectual property is corollary of capitalism. Take away intellectual property and you remove financial incentive to produce intellectual works, including software. It is awfully hard to honestly say "I'm a capitalist", then say in the same breath "I don't believe in intellectual property".
The concept that OSS even apporximates Marxism is rediculous.
I didn't say that it did "approximate Marxism". You failed to understand my post. A better way of putting it ( as some other guy did ) is this -- "Open source is voluntary". It "approximates" volunteerism
Except the GPL is his way of forcing his commie views on everyone else.
It's his property. He can release under any license he chooses. It doesn't "force" any views on anyone. And certainly doesn't force "commie" views on anyone. You are not forced to use the software. You are the one who is taking an anti-property position here.
He has no concept of freedom.
What about the freedom to release software under the GPL ? Of course the GPL is not as free as some other licenses but that doesn't alter the fact that someone may wish to use it ( and indeed may have a legit reason for doing so. )
Communism has been tainted by the wrongs committed in its name. And many definitions of communism have it defined as a big government thing, which Linux certainly isn't. However, Linux ( esp the GPL ) does embrace certain aspects of Marxism. "Each gives according to his ability and takes according to his needs". The very idea of sharing code instead of manipulating it for profit is very Marxist.
However, Linux offers something that sample implementations of communism have failed to do -- freedom. This is why Linux appeals to those with strong libertarian sentinments. My feeling is that Linux really brings in the best of both worlds.
I disagree that open source is necessarily communist.
Linux embraces many parts of the Marxist ideology, but it's not really "communist". "Communism" is a word that has been tainted by abuses and wrongs committed in it's name.
At the same time, Linux offers the anarchic freedom one associates with Liberterianism, though Linux certainly isn't capitalist. In a way, Linux offers the best of both worlds.
Check out this excerpt from Homesteading the Noosphere: there definitely is a strong sense of ownership within the community.
Hate to say it but I don't buy this. Open source is inherently anti-property in that it weakens what one may do with their intellectual assets, and in particular, it makes it hard to manipulate those assets for profit. The "rogue patch" thing has no legal ground. There's no legal ground for one patch to be called "rogue" and another "official". A succesful fork will turn the tables here. Eric's just having a hard time explaining why Open Source is all about his own political beliefs when in fact it is not inherently rightist or leftist.
They own it , but they can't exert much control over it unless they re-release it under a different license. In particular, while it's their intellectual asset, they cannot capitalise on it.
Do you disagree that the licensing model is a less direct relationship to the costs of developer time than the co-source model?
Yes. But I am not clear on why they should be related to developer time as opposed to market value of the intellectual assets created. In some cases, it makes sense to pay for developer time ( ie custom business applications sold to one buyer ). In other cases, it doesn't ( end user apps sold to many users. )
Imagine Microsoft being a huge faction of developers accepting bids on co-source to create their software.
This poses several problems : Who would bid, and why ? if you can get the software for nothing after the developer's been paid, why bid in the first place ? This creates a disincentive to bid. You would end up with a downard spiral, and your system would collapse before it began ( which explains why we don't see anything like it in the application software market ). The other problem with your model is this -- it completely ignores the fact that after the developers are done with their time, they have an asset in their hands, and they have every right to control it. Given this, why should they give up control ?
At least at present, it doesn't appear to be making money. I'll remind you that when Microsoft were as old as Redhat ( 6yrs ), they'd already won the DOS contract with IBM.
That depends. Microsoft gives away a lot of things as loss leaders and to get people locked in. ... Giving things away isn't necessarily incompatible with capitalism.
This is a very bad example. Attempting to "lock people in" is attempting to undermine the free market. While profitable, this goes against the idea of free market capitalism. Destroy the free market and you destroy capitalism as we know it.
That has been the primary model for the past few years, but that doesn't necessa rily mean that is the only way for things to work, or that it will work forever.
can you suggest another model ? As someone who is "strongly anti-socialist", I would hope that your model doesn't come wrapped in anti-property neo Marxist rhetoric.
Unfortunately, it seems that Microsoft has been pulling out those big earnings largely by their ability to destroy markets and gobble them up.
OK, admittedly that wasn't the best example, because MS's profits are partly due to some fairly non-ideal markets ( desktop OSs ). However, there are proprietary software copmanies that bring in earnings substantially larger than all the "free software companies" put together. For example, Novell, Id Software, Adobe and Oracle corp. There are also several companies that sell "solutions" that are in part proprietary software, such as Sun Microsystems ( who have been astronomically succesful ), SAP, IBM, etc. Out of these, at least IBM and MSFT are Dow 30 companies, and ORCL are fortune-100. It seems clear that overall, proprietary software does bring in large amounts of money.
The fact that profits go up and down, and some businesses come and go is orthogonal to my point -- that proprietary software brings in money, big money.
more than you can say that no Linux company will make substantial profits over the next two years.
I wouldn't go so far as to say that no Linux company will turn profit. I believe for example that Linuxcare and VA could make some money. VA actually have a decent revenue source, while redhat rely on tiny little $50- box sets for their income.
What I see as the big problem is this -- no one is going to make money by developing for Linux, because the company are paying for the creation of assets that they do not own. I see this as an economic disincentive for companies such as Redhat to pay for Linux development. I don't believe Redhat's idea of funding GNOME development makes good business sense, and I don't think it is sustainable ( though making modest donations to the projects is a different matter. )
The problem is that the paradigm whereby you don't pay developers is hardly one which is going to attract developers to the LInux platform.
With most proprietary software, you pay a per license fee, which means that the underlying cost (time to develop said software) has a strange relationship to the actual monetary value paid for the software.
You speak as though this model is unprecendented in a capitalist economy, but actually, it exists in many other examples. The proprietary software industry is about the creation of intellectual assets, and using those assets to generate income streams. Using assets to generate income streams is not a concept unique to the software industry. You see it in investment, real estate leasing, and a less tangible example, Amway diamonds generate an income stream by virtue of having earned their title.
The economic cost is paid once. The monetary cost is paid repeatedly. This suggests an inefficiency that could potentially be avoided.
The order tin which the transactions occur does not seem terribly relevant. The intellectual asset ( being the software ) has a certain NPV, and that NPV is equal to the size of the income stream that it can generate, which is in turn ( assuming a competitive market ) determined by market forces. In other words, despite the lack of synchronicity between payment and development costs, the software ultimately makes whatever money it's worth ( worth being something determined by market forces ).
The Linux business model seems to be to not pay for the software, but rather, pay for ongoing support.
The problem with this is that it presupposes that developer time has no economic value, because the intellectual assets they create are freely distributed.
by using a weakly related activity to generate money
I don't see how it's "weakly related" in the proprietary case. They are essentially capitalising on their assets through licensing. This would seem to be obviously related to the creation of those assets.
It seems to me that in one case, the cost is overpaid (license fees)
Empirical data would disagree with this assertion. assuming a competitive market, proprietary software is not overly expensive ( for example, games which truly satisfy "free market" axioms are very reasonably priced ). The problems come when we see monopolies and collusive oligopolies. Besides that, the prices are determined by the market.
If it turns out it is underpaid, then maybe the Linux companies are doomed to failure
The existing model for application has some problems simply because Redhat get no competitive advantage from paying free software developers. These developers are relying on donations alone ( the RH contributions are analagous to donations to the "free software community" IMO. Redhat give because of a shared interest, but don't get control of the projects. )
I like your other suggestion -- that they come up with something better. Let's hope so (-;
Slashdot Mirror
Wierd people like graphics professionals
I dont. Color displays correctly, thats all I care about.
Just because you don't use it or don't understand why it's useful does not mean that others can't/wont benefit from it.
Thats something else X does better then Windows or MacOS, it allows you to use different font engine servers, over a network even.
Oh my oh my, this is a stunningly ignorant comment. The advantage of font management under MacOS and Windows, that you seem unable to grok, is the fact that WYSIWYG printing is actually possible. That is, if you can display a font, you can also print it with the same methods. This is simply not true on Linux. ( QT tries to do this, but unsuccesfully. It tries to guess printer font names from the screen font names, but this is very hit and miss, and requires the user to configure their ghostscript fontmap or their printer / PPD ) In general, you cannot print fonts for a few reasons -- some of the fonts are bitmaps, which cannot be scaled to printer resolutions. There are more problems though -- X does not give the developer a way of retrieving outline files and metrics for the fonts. By the time font data reaches the X client, its already simply bitmap data. This means that there is no way for a developer to print screen fonts reliably. In case it's not blatantly obvious at this stage, let me inform you that this means that in general, WYSIWYG printing is nontrivial and involves a lot of ugly kludges. Applixware, Star Office, and Abiword all resort to ugly kludges to handle fonts. It appears that Koffice, which seems to use QTs font handling functions simply cannot print reliably.
Where's the unified print/display model? Its called PostScript....
No, this is not built into the display, at least not in older XFree86 releases. Consequently, it's not built into the toolkits. You've obviously never tried to program any WYSIWYG apps, because if you did, you'd understand how trivial WYSIWYG printing isn't. Tell me this -- how do you write a program, using just the X APIs, that displays a font, and prints that same font ? Once you can do this, you can come back and talk to us about "unified print/display models".
They seem quite usable to me and many other people, who are you to say they aren't?
Again this stupid and childish attitude. You're telling users that if they want these features, they're idiots and they should go away. But who are you to say this ? Are you a developer ? ( it doesn't sound like you understand any of the issues regarding developing GUI apps on UNIX, quite frankly )
Well, that's really nice. Unfortunately, it's also not terribly useful until X ( in particular the X font server ) supports antialiasing, because most GUI toolkits use a font model that sits on top of the X11 font APIs.
Well there doesnt seem to be any reason to "update" it, because that really isnt broke, so why fix a problem that isnt there?
It's a good thing other Linux developers don't have your attitude otherwise we'd still be in caves. X certainly could use DPS ( which is fortunately being added, probably much to your disgust )
The fact is that most users upgrade their hardware faster than they upgrade their OS. Anyone who's bought a computer in the last 3 years most probably had Win95 preloaded. And any computer over 3 years old has depreciated so much that it's difficult to give away.
In the free software world, change is more incremental. 1994 versions of Linux can run the latest software.
If you count libc as part of "Linux", then that's simply not true. libc has gone through 2 major changes. To have any chance of running the latest binaries, you'll need a new distribution.
And above all, if your mum did need a new version of Linux, perhaps to use that new printer she just bought, she could get it for free.
If the printer works with Linux, it will also work with Windows 3.1
What do you mean by running GNOME or KDE ? It's true that you need the shared libraries installed. To run Motif apps, you need Motif installed, to run Tk apps, you need Tk installed. To run KDE/QT apps, you need the KDE API ( kdelibs and kdesupport ) and QT installed. You do not need to run a KDE/GNOME panel/window manager etc.
There must be a root menu in the lower left corner There must be a task list along the bottom edge of the screen There must be an X in the upper right to close the window
No. You are confusing the desktop environment itself with the APIs. KDE/GNOME are two things. They are a set of APIs and they are "desktop environments". Running KDE/GNOME apps requires only that you have those APIs installed.
I think this needs to be implemented somewhere though. Making X antialias is difficult because this would require modifying the way X works ( and would cause possible compatibility problems ).
BTW, antialiasing is only half of the problem. The other problem is the fact that outline files and font metrics are unavailable through the X APIs. This is essential for WYSIWYG printing, because at present, all one can do is grab bitmaps from the X server, but to print, you need the outline files associated to the fonts ( unless you're content to print at screen resolutions ), or you need to know the printer name of the font and have an entry for your font in the ghostscript Fontmap.
But Applix isn't statically linked. See "gzub"s post.
-monotype-arial-medium-r-normal--0-0-0-0-p-0-iso8
The end result is that sometimes, your fonts print right and sometimes they don't. Of course, there is a way around this: You simply work out what names Koffice is guessing for the fonts, and add the appropriate mappings to your ghostscript Fontmap
However, they really do IMO need to do something about the screenprint font mapping problem. In fact, IMO one of the main things Linux needs right now is a standard way of providing the developers with the means to grab a shape file ( if there is one available ) from a screen font name.
BTW, they are not "crying" for authors, and they are not so desperate for authors that they are willing to accomodate to laziness. As much as making it easy is good, you have to understand that HOWTOs don't write themselves, it does actually involve some effort on the part of the author. I'll say it again, the technical skills requirements for writing HOWTOs are minimal. The real work is in writing the content.
And you didn't answer my question -- what format do you propose as an alternative to Linuxdoc ?
Wrong, buddy. Upgrading glibc is plain difficult, because it requires upgrading everything that links to it which is basically every dynamically linked program on your system. The only sensible way to "upgrade" is leave your old libc there and run a hybrid install, but this is difficult, and has a lot of technical difficulties, none of which are Redhat's fault.
If RatHead would make it easy, there would be an RPM to upgrade your libc.
THere is. It's called glibc. The problem is that you also need to upgrade every single application at the same time to a version that is built against the new upgraded glibc.
If you compile all the applications in a distribution in a way that they need the libc at runtime, you would have to recompile every app you use.
Exactly.
and YES, it IS the best way to handle programs, but it's also the best way to force someone to reinstall everything again (read: BUY AGAIN).
Get a grip, buddy. Linux is free ! And CDs are available for next to nothing. Hell, you can probably get someone in your Linux users group to burn you one. My group are always giving out CDs.
SOLUTION: Let the customer who buys a distribution decide whether to trade upgradabiltiy (nice word, hey?) for small apps, with better, overall performance (unless RAM is not an issue and your CPU is fast enough). Let him have the choice to have bigger programs (not dynamically linked) and the chance to upgrade the ESSENTIAL libc. I don't see this happen in my lifetime.
There is little demand for apps statically linked to libc , because most users don't want to load one copy of libc for each process on their system. I have 55 processes running right now. My libc is 4MB. Do the math -- most users don't have this much RAM to burn.
What the hell is a "desaster" ? Anyway, writing in LinuxDoc isn't very hard. Anyone who's written in HTML before can pick it up in minutes. ( "writing in SGML" doesn't make much sense. One writes to an SGML DTD like LinuxDoc, HTML, or Docbook ) For those who can't handle the simple task of learning a simple DTD, there's Lyx ( it'd be good if they'd point to Lyx as an authoring tool )
I am curious as to what format you'd propose over LinuxDoc or Docbook. The requirements are that it should be convertable into several formats, and it should have some logical structure ( so that you can convert it ).
You will not attract a huge bunch of professional technical writers if you don't lower the bar.
I don't like the idea of making the bar too low. I wouldn't want someone who is unwilling to spend a few minutes reading the HOWTO-HOWTO as a HOWTO maintainer ( you know, HOWTOs are not write-only )
sgml2latex --output=tex index.sgml
sed -e '/\\usepackage{t1enc}/d' \
-e '/\\usepackage{babel}/d' \
-e '/\\usepackage[latin1]/d' \
-e 's/\\usepackage{null}/\\usepackage{null}\\usepack
index.tex > index2.tex
mv index2.tex index.tex
pdflatex index.tex
This seems to generate good PDF files ( at least with my HOWTO, it does )
Yes, but you are presumably sitting further from the 38" monitor than the 19 inch. My 19" takes up all except my peripheral vision. If you compare this with other ultra-large ( > 21' ) display monitors, you'llfind it's in the same league resolution-wise
You hardly need to be a calculus expert to understand what an integral sign means.
Most of the interesting things (unfortunately) have a shit load of math behind them.
I did calc in high school. It hardly constitutes a "shitload" of math. You're right that a lot of things need basic math. It's got nothing to do with "elitism" or "keeping the rabble out", or "keeping it expensive" -- I don't know about you but my high school education was free. It's got to do with the fact that the moment you start doing anything quantitative or analytical, you inevitably need some math. In other words, real scientists need to know some math. The fact that you can throw together some code does not make you a computer scientist.
Well IMO, capitalism really didn't "exist very well" prior to the 1800's. Most capitalist societies of those days were barbaric by todays standards. There was no notion of a "publically held" company ( they were just moving towards that around 1800 ).
Moreover, there were many differences between the 1800s and nowadays. Piracy is much easier now than it was then. It was much less of a problem in the 1800s, since duplicating media was not very easy until quite recently ( try burning an LP on your hi fi system some time ... )
Not everyone even accepts that there exists a valid form of property. Those who believe exclusively in weaker notions of "property" are still anti-property, but less so than those who don't acknowledge any concept of property.
Intellectual property is corollary of capitalism. Take away intellectual property and you remove financial incentive to produce intellectual works, including software. It is awfully hard to honestly say "I'm a capitalist", then say in the same breath "I don't believe in intellectual property".
The concept that OSS even apporximates Marxism is rediculous.
I didn't say that it did "approximate Marxism". You failed to understand my post. A better way of putting it ( as some other guy did ) is this -- "Open source is voluntary". It "approximates" volunteerism
It's his property. He can release under any license he chooses. It doesn't "force" any views on anyone. And certainly doesn't force "commie" views on anyone. You are not forced to use the software. You are the one who is taking an anti-property position here.
He has no concept of freedom.
What about the freedom to release software under the GPL ? Of course the GPL is not as free as some other licenses but that doesn't alter the fact that someone may wish to use it ( and indeed may have a legit reason for doing so. )
However, Linux offers something that sample implementations of communism have failed to do -- freedom. This is why Linux appeals to those with strong libertarian sentinments. My feeling is that Linux really brings in the best of both worlds.
Linux embraces many parts of the Marxist ideology, but it's not really "communist". "Communism" is a word that has been tainted by abuses and wrongs committed in it's name.
At the same time, Linux offers the anarchic freedom one associates with Liberterianism, though Linux certainly isn't capitalist. In a way, Linux offers the best of both worlds.
Check out this excerpt from Homesteading the Noosphere: there definitely is a strong sense of ownership within the community.
Hate to say it but I don't buy this. Open source is inherently anti-property in that it weakens what one may do with their intellectual assets, and in particular, it makes it hard to manipulate those assets for profit. The "rogue patch" thing has no legal ground. There's no legal ground for one patch to be called "rogue" and another "official". A succesful fork will turn the tables here. Eric's just having a hard time explaining why Open Source is all about his own political beliefs when in fact it is not inherently rightist or leftist.
They own it , but they can't exert much control over it unless they re-release it under a different license. In particular, while it's their intellectual asset, they cannot capitalise on it.
Yes. But I am not clear on why they should be related to developer time as opposed to market value of the intellectual assets created. In some cases, it makes sense to pay for developer time ( ie custom business applications sold to one buyer ). In other cases, it doesn't ( end user apps sold to many users. )
Imagine Microsoft being a huge faction of developers accepting bids on co-source to create their software.
This poses several problems : Who would bid, and why ? if you can get the software for nothing after the developer's been paid, why bid in the first place ? This creates a disincentive to bid. You would end up with a downard spiral, and your system would collapse before it began ( which explains why we don't see anything like it in the application software market ). The other problem with your model is this -- it completely ignores the fact that after the developers are done with their time, they have an asset in their hands, and they have every right to control it. Given this, why should they give up control ?
At least at present, it doesn't appear to be making money. I'll remind you that when Microsoft were as old as Redhat ( 6yrs ), they'd already won the DOS contract with IBM.
That depends. Microsoft gives away a lot of things as loss leaders and to get people locked in.
...
Giving things away isn't necessarily incompatible with capitalism.
This is a very bad example. Attempting to "lock people in" is attempting to undermine the free market. While profitable, this goes against the idea of free market capitalism. Destroy the free market and you destroy capitalism as we know it.
That has been the primary model for the past few years, but that doesn't necessa rily mean that is the only way for things to work, or that it will work forever.
can you suggest another model ? As someone who is "strongly anti-socialist", I would hope that your model doesn't come wrapped in anti-property neo Marxist rhetoric.
Unfortunately, it seems that Microsoft has been pulling out those big earnings largely by their ability to destroy markets and gobble them up.
OK, admittedly that wasn't the best example, because MS's profits are partly due to some fairly non-ideal markets ( desktop OSs ). However, there are proprietary software copmanies that bring in earnings substantially larger than all the "free software companies" put together. For example, Novell, Id Software, Adobe and Oracle corp. There are also several companies that sell "solutions" that are in part proprietary software, such as Sun Microsystems ( who have been astronomically succesful ), SAP, IBM, etc. Out of these, at least IBM and MSFT are Dow 30 companies, and ORCL are fortune-100. It seems clear that overall, proprietary software does bring in large amounts of money.
The fact that profits go up and down, and some businesses come and go is orthogonal to my point -- that proprietary software brings in money, big money.
more than you can say that no Linux company will make substantial profits over the next two years.
I wouldn't go so far as to say that no Linux company will turn profit. I believe for example that Linuxcare and VA could make some money. VA actually have a decent revenue source, while redhat rely on tiny little $50- box sets for their income.
What I see as the big problem is this -- no one is going to make money by developing for Linux, because the company are paying for the creation of assets that they do not own. I see this as an economic disincentive for companies such as Redhat to pay for Linux development. I don't believe Redhat's idea of funding GNOME development makes good business sense, and I don't think it is sustainable ( though making modest donations to the projects is a different matter. )
The problem is that the paradigm whereby you don't pay developers is hardly one which is going to attract developers to the LInux platform.
You speak as though this model is unprecendented in a capitalist economy, but actually, it exists in many other examples. The proprietary software industry is about the creation of intellectual assets, and using those assets to generate income streams. Using assets to generate income streams is not a concept unique to the software industry. You see it in investment, real estate leasing, and a less tangible example, Amway diamonds generate an income stream by virtue of having earned their title.
The economic cost is paid once. The monetary cost is paid repeatedly. This suggests an inefficiency that could potentially be avoided.
The order tin which the transactions occur does not seem terribly relevant. The intellectual asset ( being the software ) has a certain NPV, and that NPV is equal to the size of the income stream that it can generate, which is in turn ( assuming a competitive market ) determined by market forces. In other words, despite the lack of synchronicity between payment and development costs, the software ultimately makes whatever money it's worth ( worth being something determined by market forces ).
The Linux business model seems to be to not pay for the software, but rather, pay for ongoing support.
The problem with this is that it presupposes that developer time has no economic value, because the intellectual assets they create are freely distributed.
by using a weakly related activity to generate money
I don't see how it's "weakly related" in the proprietary case. They are essentially capitalising on their assets through licensing. This would seem to be obviously related to the creation of those assets.
It seems to me that in one case, the cost is overpaid (license fees)
Empirical data would disagree with this assertion. assuming a competitive market, proprietary software is not overly expensive ( for example, games which truly satisfy "free market" axioms are very reasonably priced ). The problems come when we see monopolies and collusive oligopolies. Besides that, the prices are determined by the market.
If it turns out it is underpaid, then maybe the Linux companies are doomed to failure
The existing model for application has some problems simply because Redhat get no competitive advantage from paying free software developers. These developers are relying on donations alone ( the RH contributions are analagous to donations to the "free software community" IMO. Redhat give because of a shared interest, but don't get control of the projects. )
I like your other suggestion -- that they come up with something better. Let's hope so (-;