I find that that just isn't the case much. Most computers I'm aware of are shared between a couple of users - owner + owner's partner, possibly + kids. And it's handy having your own account, just for simple stuff like desktop theme, recently used start-menu list, fonts, desktop icons, display resolution, etc... Then you've got email, web bookmarks + autocomplete, plugins, documents, preferred applications (e.g. juk vs. xmms), rss feed reader, calendar (surprise romantic restaurant booking, don't put on shared calendar!), etc.... It's not just for security (or hiding your pr0n:) but it's just/convenient/ for each person to have their own settings.
If you do something dumb and someone hacks your account, yes, you might lose all your files and have to restore from backup. But at least your partner won't have the same problem. They don't lose that half-day's (or half-week's, or half-however-long-you-take-between-backups) work that they did between the backup being taken and your account being pwned.
And that doesn't even take into consideration what other people have already mentioned, that you can merely restore your user files from backup instead of having to wipe the drive and reinstall & reconfigure all your system software *first* (did you remember to keep a backup of/etc?)
Sorry, I meant that I never see hardware manufacturers releasing drivers for Linux/PPC *where they don't submit them for inclusion to mainline*.
If your driver is in mainline, your worries about API/ABI changes are pretty much eliminated as the person changing the API has the responsibility to move the drivers to the new one. Which negates the GPs point about API changes being hard on the HW mfr.
"[a stable abi] means hardware manufacturers are far more likely to release drivers for your platform"
No it doesn't. I run Linux/PPC and I *never* see hardware manufacturers releasing drivers for their hardware on it. Heck, it's hard enough to get decent drivers for Linux/x86-64 from them. I don't see them doing decent drivers for a other chipsets that run on systems that use standard hardware interfaces (PCI, etc...) either. They're just not interested.
Uh, UTF-8 files do not need a BOM. What the fuck is the point of a byte-order-mark on an encoding that is byte-order neutral?
One of the advantages of UTF-8 for text files is that you don't need a BOM. With XML it's even easier because, as you point out, the XML declaration ("XMLDecl" in the spec) header can contain the "EncodingDecl" to tell explicitly you the file is in UTF-8. If the EncodingDecl says UTF-8, and the file is encoded in UTF-8, then if an XML parser cannot handle that, it's seriously fucked an needs to be fixed.
You might also want to go read STD-63 at some point. It points out that there are a few problems with using BOMs in UTF-8, and that if there is a way for UTF-8 to be determined in a way other than with the use of a BOM, that should be used instead. Given that XML specifically includes support for an "EncodingDecl" in the "XMLDecl", it is clear that best practices dictate that you *shouldn't* use a BOM when working with UTF-8 encoded XML files. Even if your tools _insist_ on writing BOMs to such files, they had *better* still be able to work if the BOM is missing.
Heck, with OOXML, you could also use the ZIP's manifest file to keep track of file metadata like the character encoding.
"Alright, I'm replying because I figure I can help you stop assuming the worst in people."
Heh. I don't assume the worst in most people, just in the people who normally post to/. And as much as I appreciate your eagerness to help, I don't think your lone voice of sanity is going to start making me think much more of the average/. poster.;-)
"Oh yeah, you're a skeptic..."
Been here too long, seen too many anecdotal claims that don't make an ounce of sense.
"an example of a project (not mine) that doesn't compile in gcc4, but compiles in gcc3 is qemu. You can go try it out yourself."
Hang on....
$ apt-get source qemu $ cd qemu-0.9.0/ $./configure
Huh!
$./configure --disable-gcc-check --disable-gfx-check $ make
Oh yeah! OK then. Our anecdotal evidence was evenly matched, but this trumps me. Fair enough.
"The program in question was comedi. You can download the cvs snapshot..."
*shakes fist at sky*
I thought of putting something about it not counting if you check out code from the repository, seeing as autogenerated files don't get put in there. Honest! But you said "downloaded a program" so I figured you meant a release tarball, which you/shouldn't/ need autotools for. Forgot some people "release" repository snapshots. (Srsly, what is the point in this? Why not just create a tag for people to check out directly?)
"I wasn't lying [...]"
OK, I believe you.
"[...] and I don't know why you'd automatically assume I was."
Dude, don't you ever read other people's comments on/.?!? Especially when discussing holy wars like editors or development environments. People always make stuff up just to rubbish the opposition, and it needs debunking. You can't let that sort of stuff go!
For example, those emacs users always lie about how you can't do X in vim despite it being easy if you'd just looked in section 28 of the reference manual. At least vim users don't have to press Ctrl+Alt+Meta+Shift+n just to get a newline!
"Why don't you try working on a c++ project with multiple developers, some of them using gcc 4.x and the others using gcc 3.x, and see what happens."
I currently am. Developers have shiny boxes with gcc 4.1.3, software is also compiled and installed on stable boxes running gcc 3.3.4. Haven't run into any problems recently.
"Hell, I had to update autotools the other day to compile a program I downloaded. For some reason, debian had a really old version of autotools installed by default."
I call bullshit. You don't need autotools installed to compile programs. The point of autotools is that the person who creates the tarball uses them to generate the "configure" shell script. To compile a program, all you should need are a posix-compliant "/bin/sh" (no, you don't even need bash) to run the configure script, "make", and an appropriate compiler.
autotools are only needed to create the configure script. You should not need to create the configure script yourself to compile the program.
Nah, I can't conceptualise it unless it's in football-field lengths. Can someone figure that out for me? Google calculator won't do "15.6 billion km in football fields" so I'm stuck.
Uh, I thought that the patent provisions in GPL3 were more to do with preventing the Novell side of the deal happening - Novell is effectively prohibited from entering it's side of the bargain. After all, they're the one distributing other people's GPL3'd code.
No, these are going to be polished releases, so are definitely deserving of the full "4.0" number. You missed the 2 Alphas, that was a while ago. This is the Beta, which is ready for some slightly more widespread testing, but not guaranteed to be completely stable. The "pre" releases, or release candidates, which should be around next month, should be almost there with only minor bugfixes in place.
All they mean is that KDE 4.0 will not have all the features that later releases of KDE 4 will have.
The point is that this is *not* commercial software, where version x.0 contains all the features you're ever going to get, and x.1, x.2, etc... just contain bug fixes and possibly a bit more shiny clip-art. I don't know if "release early, release often" can be applied to a project that's been 2 years in the making already, but if they waited until they'd written everything they could possibly think of into KDE4 before they released it, they'd probably *never* release it!
Yes, they've got a whole load more interesting ideas that will get added to future KDE 4 releases. New minor versions will have cool new functionality. They just haven't had time to do it all at once.
KDE 3.5 has a hell of a lot more stuff that KDE 3.0. But I'm glad they released KDE 3.0 in April 2002 instead of waiting until November 2005 to push it all out at once.
So, the performance suffers. But it suffers, as the GP points out, with 1Gb if you're using the full 2Gb all the time. But compared to the alternative which is.... having processes OOM-killed? You think having your movie player stutter is worse than having the it terminated by the kernel?
Hey, it's probably buffering a fair bit of data in an attempt to *not* stutter, so all that memory is going to make it a pretty good target for the OOM-killer when you do get to the limit of your 1Gb + 1Gb. Yes, it will be slow to use 11Gb. But I still fail to see how having 10Gb of swap "at best doubles" the 1Gb of RAM you started with.
Paging is slow. I'm not going to argue with that. I also think having swap is better than not having enough memory to run the apps you wanted to run. But I don't see how "paging at best doubles the effective RAM."
With well documented published formats, interoperability is increased.
However, that does not mean that OOXML needs to become an international *standard*.
If OOXML wasn't so crap, rushed or poor-quality, it might eventually make a decent standard. But it is crap. It is rushed. It is of piss-poor quality. It has obviously never been given a detailed review by anyone. No-one has ever built a product from the spec. (MS didn't write Office 2007's support from the spec, they wrote the spec from Office 2007's format). As it stands, it is not technically adequate to be a recommended standard.
No, I don't want it to be closed. I do want it to be open so that people can/try/ to write interoperable implementations, despite the many warts it has. I also want MS to open the old.doc formats more, and publish documentation for the most up-to-date versions of those formats, and allow them to be used by people writing software that competes with MS Office (which you are not allowed to do) so that other people can write interoperable implementations for other office suites. But that does not mean I want the.doc format to become an international standard.
I also want published, open, complete documentation for old Wordperfect formats, Ami Pro formats, 1-2-3 formats, etc., etc., etc., but I do not want any of *these* to become international standards either.
However, even if MS did take the 2-3 years that might be required for them to put OOXML into a good enough shape for it to be considered a standard, I'd probably *still* prefer it not to be. Having multiple standards for the same thing does not offer *useful* choice.
I don't particularly care about choice in word-processing file formats, but I *do* care about choice in word-processing *applications*. If I receive a word-processing file from someone, I want to be able to view/edit it on a device of my choice, with an application of my choice. Having multiple file formats makes this *harder* for application writers, as time spent getting the basics of 2 file formats implemented takes time away from perfecting support for 1 of them.
Do you like it when you go to another country and the plug sockets are different? Or the TV signals? How would having a choice of standard electrical connector help you at home? Or a choice of TV signal? NO! A single standard encourages multiple implementations.
If you're still unsure, give me one example of people who benefitted from having ASCII and EBCDIC as multiple standard ways of encoding plain text. Or one example of people who benefitted from VHS and Betamax. Or one example of a group of people who will benefit from having HD-DVD and Blu-Ray. Aside from the people who are trying to lock you in to their standard, and who are happy to sell you "solutions" to work around the problems that the existence of multiple standards creates, you will find no-one. No *user* of electrical appliances, of heterogenous ASCII/EBCDIC systems, of Betamax VCRs has ever benefitted from the existence of overlapping standards.
No, someone isn't violating copyright by viewing your page, but the rule doesn't talk about *violating* copyright, it talks about *downloading copyrighted materials*.
*All* works, unless they carry a notice explicitly putting them into the public domain, are automatically copyrighted by the author[0]. They do not need a copyright notice for them to be copyrighted.
Now, as the author, you may make your work (web page) available for people to download for free; that is your right. And because you, as the copyright holder, are the one who has made the work available, the end users aren't breaking copyright by downloading it.
*However*, they are still *downloading copyrighted materials*. They may be doing so legally, but that is not what the rule cares about. The rule states that merely downloading copyrighted materials is grounds for account termination.
[0] Or, if it is a work-for-hire or similar, the work might be copyrighted by an entity other than the author. But it is still copyrighted.
Heh. Maybe the problem is that not enough Linux programs come with EULAs, so that when one does pop up people actually take notice and read it.
If so, we need to add really long, legalese-laden EULAs to *all* Linux software, just like with Windows. When users get used to clicking right through them again, and one does come up that matters, they won't even notice! It'll be just like on Windows!:-/
"While the recompilations are supposed to run as a background task, in some instances the recompilation will drive the processor to 100% usage."
Um, so? If the processor isn't doing anything else, why shouldn't a background recompile use up 100% processor time? Don't tell me Windows gives time to the "idle" process when there are other processes, even background ones, that could run?!?
Oh, I definitely agree that open formats are a good idea, and that this does show one very good reason why.
But, the point is that MOOXML is a shitty open format. It was written in a closed environment, without a decent review by anyone, in 1/20th the time you'd expect a spec of that size to take, and is being put on a "fast-track" process to ISO which means - if it goes through - it will never have had a proper review by anyone.
Yes, having the format be open is a good thing.
But this format is utter crap, on many different levels. It's size, complexity, inconsistency, bugginess, NIH-iness, reliance on Win32, etc., etc., etc.... make it completely unsuitable to be ratified as an ISO standard.
When you're turning something into an international standard, you want to take your time and get it right. That's what the standardisation process should be about. Creating something usable by as many parties as possible. MOOXML fails completely here.
Yes, I'm in favour of them opening their document formats. I wish they'd release updated documentation for the binary.doc format as well, usable by anyone (last I checked there was a "you must agree not to use this information to create products that compete with office" clause in the (outdated) documentation download) so that people could interoperate with those formats on non-Windows platforms. But do I wish for the binary.doc format to be an international standard? Hell no!
Sorry - I thought you were concentrating on nVidia - most people complaining about not having a stable kernel interface do:)
Rich0 might have said "The whole point of the no-binary-interface to the kernel is to make your life as big of a pain as possible." but that doesn't make it true. Read the stable-api-nonsense and ols-keynote pages that I linked to again. There are a number of reasons for not maintaining a stable api to the kernel, and most of them have to do with allowing the rest of the kernel to improve in areas such as speed, security, flexibility, portability, etc, etc, etc...
That binary-only driver writers are screwed is merely a handy side-effect:)
But yes, for some old drivers for which there isn't much hardware left, the last few users who still have that hardware will probably end up becoming unfortunate testers, which isn't ideal. I don't know what to do about that one, and still keep all the advantages of not having a stable in-kernel API. It is a trade-off.
Is the trade off of having the occasional piece of old hardware for which there aren't many testers available break worth not having, e.g. 3 different USB cores? In the long term? I'd say yes, it is the right trade-off. I'll admit that doesn't make the down-side go away, but at least it's not being done "just to make things harder for you".:-/
No, I'm saying that once the code is in the main kernel tree, nVidia can still do all the testing. They can check out a the latest development revision, and run all their tests on all the hardware they own. If they find any bugs:
a) *nVidia* can report bugs to the lkml. b) *nVidia* can send patches to the lkml to fix bugs before the next release.
*nVidia are just as capable of testing code in the mainline kernel as any kernel developer.* As nVidia does testing/maintenance of their kernel/blob glue now, they can continue to do it directly on the driver if the driver is in the mainline kernel, and continue to feed patches back. Only this time they'll get a lot more help from the rest of the kernel hackers. Even/if/ the glue layer makes their blob legal, they're still currently trying to game the system, and giving every kernel developer who has ever released/their/ code the finger, which isn't going to be making any of the kernel hackers predisposed to helping them at the moment.
If licenses and contracts stop nVidia from creating proper (read: GPLd and in the mainline kernel) drivers for Linux, but nVidia want to support Linux, then perhaps they should rethink which licences and contracts they sign. No-one's forcing them to sign anything....
Having a driver in the main kernel tree does not automatically stop nVidia from continuing to contribute to it. If they got their driver in, nVidia could still test the driver on all the hardware they currently do testing on, once per revision (every 2-3 months months) and file bug reports/patches for any problems they found. Yes, they'll have to accept that other people might post patches as well that might get included, but most 3rd party patches will probably be either bug fixes, or changes to accommodate fixes to the rest of the kernel.
When the nVidia engineers are not doing the once-per-couple-of-months testing cycle, they can continue to work on improvements. If the test suite is automated (which it should be) this should involve no more than clicking on the "start" button and waiting for the result in the common case where there are no regressions.
And if the drivers are in the main kernel tree, you won't have to recompile them - they'll be distributed with the kernel. You won't have to download them either - they'll be distributed with the kernel.
I'd also be somewhat surprised if having a few of the best Linux brains on the planet - the kernel developers - go over the code, did not give any quality improvements. I have to admit, there's no guarantee that the quality would go up, but I'd consider it very likely. Have you *seen* much proprietary code?;)
Slashdot Mirror
"I am the only user of my system."
:) but it's just /convenient/ for each person to have their own settings.
/etc?)
I find that that just isn't the case much. Most computers I'm aware of are shared between a couple of users - owner + owner's partner, possibly + kids. And it's handy having your own account, just for simple stuff like desktop theme, recently used start-menu list, fonts, desktop icons, display resolution, etc... Then you've got email, web bookmarks + autocomplete, plugins, documents, preferred applications (e.g. juk vs. xmms), rss feed reader, calendar (surprise romantic restaurant booking, don't put on shared calendar!), etc.... It's not just for security (or hiding your pr0n
If you do something dumb and someone hacks your account, yes, you might lose all your files and have to restore from backup. But at least your partner won't have the same problem. They don't lose that half-day's (or half-week's, or half-however-long-you-take-between-backups) work that they did between the backup being taken and your account being pwned.
And that doesn't even take into consideration what other people have already mentioned, that you can merely restore your user files from backup instead of having to wipe the drive and reinstall & reconfigure all your system software *first* (did you remember to keep a backup of
Rubbish.
It's just as accurate to say you own a copy of Linux as it is to say you own a copy of a book.
In neither case do you own the copyright for the item in question, but you do own the copy you have.
You own books, don't you?
Sorry, I meant that I never see hardware manufacturers releasing drivers for Linux/PPC *where they don't submit them for inclusion to mainline*.
If your driver is in mainline, your worries about API/ABI changes are pretty much eliminated as the person changing the API has the responsibility to move the drivers to the new one. Which negates the GPs point about API changes being hard on the HW mfr.
"[a stable abi] means hardware manufacturers are far more likely to release drivers for your platform"
No it doesn't. I run Linux/PPC and I *never* see hardware manufacturers releasing drivers for their hardware on it. Heck, it's hard enough to get decent drivers for Linux/x86-64 from them. I don't see them doing decent drivers for a other chipsets that run on systems that use standard hardware interfaces (PCI, etc...) either. They're just not interested.
The only way to get a decent driver for Linux (Not Linux/x86-32, but Linux) is for it to be in the main kernel tree.
Uh, UTF-8 files do not need a BOM. What the fuck is the point of a byte-order-mark on an encoding that is byte-order neutral?
One of the advantages of UTF-8 for text files is that you don't need a BOM. With XML it's even easier because, as you point out, the XML declaration ("XMLDecl" in the spec) header can contain the "EncodingDecl" to tell explicitly you the file is in UTF-8. If the EncodingDecl says UTF-8, and the file is encoded in UTF-8, then if an XML parser cannot handle that, it's seriously fucked an needs to be fixed.
You might also want to go read STD-63 at some point. It points out that there are a few problems with using BOMs in UTF-8, and that if there is a way for UTF-8 to be determined in a way other than with the use of a BOM, that should be used instead. Given that XML specifically includes support for an "EncodingDecl" in the "XMLDecl", it is clear that best practices dictate that you *shouldn't* use a BOM when working with UTF-8 encoded XML files. Even if your tools _insist_ on writing BOMs to such files, they had *better* still be able to work if the BOM is missing.
Heck, with OOXML, you could also use the ZIP's manifest file to keep track of file metadata like the character encoding.
"Alright, I'm replying because I figure I can help you stop assuming the worst in people."
/. And as much as I appreciate your eagerness to help, I don't think your lone voice of sanity is going to start making me think much more of the average /. poster. ;-)
./configure
./configure --disable-gcc-check --disable-gfx-check
/shouldn't/ need autotools for. Forgot some people "release" repository snapshots. (Srsly, what is the point in this? Why not just create a tag for people to check out directly?)
/.?!? Especially when discussing holy wars like editors or development environments. People always make stuff up just to rubbish the opposition, and it needs debunking. You can't let that sort of stuff go!
Heh. I don't assume the worst in most people, just in the people who normally post to
"Oh yeah, you're a skeptic..."
Been here too long, seen too many anecdotal claims that don't make an ounce of sense.
"an example of a project (not mine) that doesn't compile in gcc4, but compiles in gcc3 is qemu. You can go try it out yourself."
Hang on....
$ apt-get source qemu
$ cd qemu-0.9.0/
$
Huh!
$
$ make
Oh yeah! OK then. Our anecdotal evidence was evenly matched, but this trumps me. Fair enough.
"The program in question was comedi. You can download the cvs snapshot..."
*shakes fist at sky*
I thought of putting something about it not counting if you check out code from the repository, seeing as autogenerated files don't get put in there. Honest! But you said "downloaded a program" so I figured you meant a release tarball, which you
"I wasn't lying [...]"
OK, I believe you.
"[...] and I don't know why you'd automatically assume I was."
Dude, don't you ever read other people's comments on
For example, those emacs users always lie about how you can't do X in vim despite it being easy if you'd just looked in section 28 of the reference manual. At least vim users don't have to press Ctrl+Alt+Meta+Shift+n just to get a newline!
"Why don't you try working on a c++ project with multiple developers, some of them using gcc 4.x and the others using gcc 3.x, and see what happens."
I currently am. Developers have shiny boxes with gcc 4.1.3, software is also compiled and installed on stable boxes running gcc 3.3.4. Haven't run into any problems recently.
"Hell, I had to update autotools the other day to compile a program I downloaded. For some reason, debian had a really old version of autotools installed by default."
I call bullshit. You don't need autotools installed to compile programs. The point of autotools is that the person who creates the tarball uses them to generate the "configure" shell script. To compile a program, all you should need are a posix-compliant "/bin/sh" (no, you don't even need bash) to run the configure script, "make", and an appropriate compiler.
autotools are only needed to create the configure script. You should not need to create the configure script yourself to compile the program.
So, bullshit.
Nah, I can't conceptualise it unless it's in football-field lengths. Can someone figure that out for me? Google calculator won't do "15.6 billion km in football fields" so I'm stuck.
Sorry, can't resist. You should also create a http://redhat.com/~mingo/leartime-patches/ set to translate all the kernel messages into Shakespearian English.
Hey, do you ever get that mixed up with http://redhat.com/~mingo/realtime-patches/ ? :)
Uh, I thought that the patent provisions in GPL3 were more to do with preventing the Novell side of the deal happening - Novell is effectively prohibited from entering it's side of the bargain. After all, they're the one distributing other people's GPL3'd code.
Or did I miss something?
No, these are going to be polished releases, so are definitely deserving of the full "4.0" number. You missed the 2 Alphas, that was a while ago. This is the Beta, which is ready for some slightly more widespread testing, but not guaranteed to be completely stable. The "pre" releases, or release candidates, which should be around next month, should be almost there with only minor bugfixes in place.
All they mean is that KDE 4.0 will not have all the features that later releases of KDE 4 will have.
The point is that this is *not* commercial software, where version x.0 contains all the features you're ever going to get, and x.1, x.2, etc... just contain bug fixes and possibly a bit more shiny clip-art. I don't know if "release early, release often" can be applied to a project that's been 2 years in the making already, but if they waited until they'd written everything they could possibly think of into KDE4 before they released it, they'd probably *never* release it!
Yes, they've got a whole load more interesting ideas that will get added to future KDE 4 releases. New minor versions will have cool new functionality. They just haven't had time to do it all at once.
KDE 3.5 has a hell of a lot more stuff that KDE 3.0. But I'm glad they released KDE 3.0 in April 2002 instead of waiting until November 2005 to push it all out at once.
Mod parent up.
So, the performance suffers. But it suffers, as the GP points out, with 1Gb if you're using the full 2Gb all the time. But compared to the alternative which is .... having processes OOM-killed? You think having your movie player stutter is worse than having the it terminated by the kernel?
Hey, it's probably buffering a fair bit of data in an attempt to *not* stutter, so all that memory is going to make it a pretty good target for the OOM-killer when you do get to the limit of your 1Gb + 1Gb. Yes, it will be slow to use 11Gb. But I still fail to see how having 10Gb of swap "at best doubles" the 1Gb of RAM you started with.
Paging is slow. I'm not going to argue with that. I also think having swap is better than not having enough memory to run the apps you wanted to run. But I don't see how "paging at best doubles the effective RAM."
"paging at best doubles the effective RAM."
Could you explain that one a bit more? If you have 1Gb RAM and 10Gb swap, how is the effective RAM limited to 2Gb at best?
You're mostly right.
/try/ to write interoperable implementations, despite the many warts it has. I also want MS to open the old .doc formats more, and publish documentation for the most up-to-date versions of those formats, and allow them to be used by people writing software that competes with MS Office (which you are not allowed to do) so that other people can write interoperable implementations for other office suites. But that does not mean I want the .doc format to become an international standard.
With well documented published formats, interoperability is increased.
However, that does not mean that OOXML needs to become an international *standard*.
If OOXML wasn't so crap, rushed or poor-quality, it might eventually make a decent standard. But it is crap. It is rushed. It is of piss-poor quality. It has obviously never been given a detailed review by anyone. No-one has ever built a product from the spec. (MS didn't write Office 2007's support from the spec, they wrote the spec from Office 2007's format). As it stands, it is not technically adequate to be a recommended standard.
No, I don't want it to be closed. I do want it to be open so that people can
I also want published, open, complete documentation for old Wordperfect formats, Ami Pro formats, 1-2-3 formats, etc., etc., etc., but I do not want any of *these* to become international standards either.
However, even if MS did take the 2-3 years that might be required for them to put OOXML into a good enough shape for it to be considered a standard, I'd probably *still* prefer it not to be. Having multiple standards for the same thing does not offer *useful* choice.
I don't particularly care about choice in word-processing file formats, but I *do* care about choice in word-processing *applications*. If I receive a word-processing file from someone, I want to be able to view/edit it on a device of my choice, with an application of my choice. Having multiple file formats makes this *harder* for application writers, as time spent getting the basics of 2 file formats implemented takes time away from perfecting support for 1 of them.
Do you like it when you go to another country and the plug sockets are different? Or the TV signals? How would having a choice of standard electrical connector help you at home? Or a choice of TV signal? NO! A single standard encourages multiple implementations.
If you're still unsure, give me one example of people who benefitted from having ASCII and EBCDIC as multiple standard ways of encoding plain text. Or one example of people who benefitted from VHS and Betamax. Or one example of a group of people who will benefit from having HD-DVD and Blu-Ray. Aside from the people who are trying to lock you in to their standard, and who are happy to sell you "solutions" to work around the problems that the existence of multiple standards creates, you will find no-one. No *user* of electrical appliances, of heterogenous ASCII/EBCDIC systems, of Betamax VCRs has ever benefitted from the existence of overlapping standards.
No, someone isn't violating copyright by viewing your page, but the rule doesn't talk about *violating* copyright, it talks about *downloading copyrighted materials*.
*All* works, unless they carry a notice explicitly putting them into the public domain, are automatically copyrighted by the author[0]. They do not need a copyright notice for them to be copyrighted.
Now, as the author, you may make your work (web page) available for people to download for free; that is your right. And because you, as the copyright holder, are the one who has made the work available, the end users aren't breaking copyright by downloading it.
*However*, they are still *downloading copyrighted materials*. They may be doing so legally, but that is not what the rule cares about. The rule states that merely downloading copyrighted materials is grounds for account termination.
[0] Or, if it is a work-for-hire or similar, the work might be copyrighted by an entity other than the author. But it is still copyrighted.
Heh. Maybe the problem is that not enough Linux programs come with EULAs, so that when one does pop up people actually take notice and read it.
:-/
If so, we need to add really long, legalese-laden EULAs to *all* Linux software, just like with Windows. When users get used to clicking right through them again, and one does come up that matters, they won't even notice! It'll be just like on Windows!
"While the recompilations are supposed to run as a background task, in some instances the recompilation will drive the processor to 100% usage."
Um, so? If the processor isn't doing anything else, why shouldn't a background recompile use up 100% processor time? Don't tell me Windows gives time to the "idle" process when there are other processes, even background ones, that could run?!?
Oh, I definitely agree that open formats are a good idea, and that this does show one very good reason why.
.doc format as well, usable by anyone (last I checked there was a "you must agree not to use this information to create products that compete with office" clause in the (outdated) documentation download) so that people could interoperate with those formats on non-Windows platforms. But do I wish for the binary .doc format to be an international standard? Hell no!
But, the point is that MOOXML is a shitty open format. It was written in a closed environment, without a decent review by anyone, in 1/20th the time you'd expect a spec of that size to take, and is being put on a "fast-track" process to ISO which means - if it goes through - it will never have had a proper review by anyone.
Yes, having the format be open is a good thing.
But this format is utter crap, on many different levels. It's size, complexity, inconsistency, bugginess, NIH-iness, reliance on Win32, etc., etc., etc.... make it completely unsuitable to be ratified as an ISO standard.
When you're turning something into an international standard, you want to take your time and get it right. That's what the standardisation process should be about. Creating something usable by as many parties as possible. MOOXML fails completely here.
Yes, I'm in favour of them opening their document formats. I wish they'd release updated documentation for the binary
From TFA:
"Across the NVIDIA Linux Graphics Driver team, everyone has their own favorite Linux distribution as their primary desktop: Debian, [...]"
Interesting, given that Debian can't ship their driver.
Oh, I know that none of the driver team will be using a distro-bundled version of the driver anyway, but still...
Sorry - I thought you were concentrating on nVidia - most people complaining about not having a stable kernel interface do :)
:)
:-/
Rich0 might have said "The whole point of the no-binary-interface to the kernel is to make your life as big of a pain as possible." but that doesn't make it true. Read the stable-api-nonsense and ols-keynote pages that I linked to again. There are a number of reasons for not maintaining a stable api to the kernel, and most of them have to do with allowing the rest of the kernel to improve in areas such as speed, security, flexibility, portability, etc, etc, etc...
That binary-only driver writers are screwed is merely a handy side-effect
But yes, for some old drivers for which there isn't much hardware left, the last few users who still have that hardware will probably end up becoming unfortunate testers, which isn't ideal. I don't know what to do about that one, and still keep all the advantages of not having a stable in-kernel API. It is a trade-off.
Is the trade off of having the occasional piece of old hardware for which there aren't many testers available break worth not having, e.g. 3 different USB cores? In the long term? I'd say yes, it is the right trade-off. I'll admit that doesn't make the down-side go away, but at least it's not being done "just to make things harder for you".
No, I'm saying that once the code is in the main kernel tree, nVidia can still do all the testing. They can check out a the latest development revision, and run all their tests on all the hardware they own. If they find any bugs:
/if/ the glue layer makes their blob legal, they're still currently trying to game the system, and giving every kernel developer who has ever released /their/ code the finger, which isn't going to be making any of the kernel hackers predisposed to helping them at the moment.
a) *nVidia* can report bugs to the lkml.
b) *nVidia* can send patches to the lkml to fix bugs before the next release.
*nVidia are just as capable of testing code in the mainline kernel as any kernel developer.* As nVidia does testing/maintenance of their kernel/blob glue now, they can continue to do it directly on the driver if the driver is in the mainline kernel, and continue to feed patches back. Only this time they'll get a lot more help from the rest of the kernel hackers. Even
If licenses and contracts stop nVidia from creating proper (read: GPLd and in the mainline kernel) drivers for Linux, but nVidia want to support Linux, then perhaps they should rethink which licences and contracts they sign. No-one's forcing them to sign anything....
Having a driver in the main kernel tree does not automatically stop nVidia from continuing to contribute to it. If they got their driver in, nVidia could still test the driver on all the hardware they currently do testing on, once per revision (every 2-3 months months) and file bug reports/patches for any problems they found. Yes, they'll have to accept that other people might post patches as well that might get included, but most 3rd party patches will probably be either bug fixes, or changes to accommodate fixes to the rest of the kernel.
;)
When the nVidia engineers are not doing the once-per-couple-of-months testing cycle, they can continue to work on improvements. If the test suite is automated (which it should be) this should involve no more than clicking on the "start" button and waiting for the result in the common case where there are no regressions.
And if the drivers are in the main kernel tree, you won't have to recompile them - they'll be distributed with the kernel. You won't have to download them either - they'll be distributed with the kernel.
I'd also be somewhat surprised if having a few of the best Linux brains on the planet - the kernel developers - go over the code, did not give any quality improvements. I have to admit, there's no guarantee that the quality would go up, but I'd consider it very likely. Have you *seen* much proprietary code?
You think you want a stable kernel interface, but you really do not, and you don't even know it.