Actually, the statistical significance of either Gore's lead in the popular vote or Bush's lead in Florida is as follows: both are impossible to distinguish from pure chance.
Understand what this means. Mathematically, inconvertibly so, the presidency was won on a coin toss.
50% +1 is a quaint holdover from times past. We have long surpassed its capacity for accuracy. You cant exactly announce to 100,000,000 million people "all for Bush say aye. All for Gore, nay. Ok, the ayes have it." Well, you can and you do but you also hope that the result is statistically significant.
It wasnt this time. Not by a long shot.
Truly a remarkable event. I'll leave to someone else to ponder out loud what the chances of such an event occuring were in the first place:-)
The BSD license allows for closed licensing around the licensed code. Releasing something under the BSD license is tacitly approving of such a thing. I'm not saying that's bad, nor, I think, did the original poster. It's just that you do accept that, and you have to in turn accept the concequences
That is absolutely acceptable to BSD advocates.
That is, you will have to accept the fact that Microsoft is going to use your code and never contribute back.
I have no problem with that. If they use the better code, the world is that much better off for it. My hatred for MS buys me nothing - especially if I have to use their product for one reason or another (choice included.) If they have the resources to maintain an independent fork, bully for them. The original code remains under continued OSS development.
Best of both worlds as far as I can see.
(I dont understand where I introduced a strawman in my original arguement. I maintain that the standard GPL relicensing arguement is entirely based on one big strawman, actually.)
We look down on GNU/Linux bigots because they're naive morons. We have much more sympathy for their parents who house and shelter them by virtue of exacting a living wage from fearsome, capitalist exploiters of Information that Wants to be Free.
The problem with non linear, hyperlinked information is that it practically enforces casual skimming as opposed to reading in depth[*]. Its no accident web sites are dumbed down, you know. This is also why I have problems with web content in school curriculums; I'm not sure I want any of my kids being taught attention disorder, for lack of a better word.
[*] "I'll read this later, there's still a few more links to follow," kind of thing. Its hard to absorb good information off the web, isnt it? How many of you have read 1/100th of your book marked pages? Not many, I bet. I've often found myself spending more time gathering links than actually reading the information I originally sought.
There is no reason not to open source the kernel because no one writes to the kernel. (Even NT apps are almost all entirely Win32, an api on top of the NT kernel.) It doesnt matter whether its open source or not. The OS X, api's are another matter entirely, however. They may not be able to keep a lid under posix, but they as hell can - AND WILL - keep carbon and all the other apis strictly proprietary.
Again, something no one programs directly is a free lunch.
Or windows, or BeOS or CP/M. Darwin has a microkernel, FreeBSD does not. That itself makes it an object of interest, at least. Linus notwithstanding, a kernel hacker can lear a lot from running darwin.
X had Aqua so there is a reason to use it.
X has Aqua, does it? Here, pull my finger.
Why develop software for Apple to get rich on and get nothing in return?
Why develop software for RedHat, Corel, Caldera, etc and get nothing in return? OSS software is OSS software. Deal with it. (Not that you, personally, would develop anything other toner smudges on your fingers.)
Do I look stoopid?
Well, you arent entirely the brightest bulb on the christmas tree.
XML documents are not meant to be read by humans. Humans are a last resort, in case of emergency. XML documents are meant to be read, displayed and manipulated by computers.
If you think this is meaningless, if you think this is of no use, you are welcome to uninstall libxml from your machine, write a parser for every program you develop, and have it promptly ignored by the general community.
Its your call. Personally, the one thing I enjoy less than UI code is code to translate and interchange data between apps and systems. XML solves that problem and allows me that much more time to be productive or goof off.
The above could all be achieved with a linux distribution.
No, it cant. You'd need to merge DEVELOPMENT of kernel AND userland software for that to happen in any remotely effective manner. FreeBSD isnt a distribution in the sense Linux users understand. Even 3rd party ports have a structure imposed upon them. Their sources, when installed, all live under a single directory structure which is readily grokked and upgradeable.
This is Linux's biggest failing, for me, that it is merely a kernel There is a distinct lack of cohesion that simply _cannot_ be addressed by any distribution. Performance issues are a wash. Sometimes FreeBSD is faster, sometimes Linux. The numbers never justify any crowing, though.
The cohesion extends into policy, as well. Changes arent committed to ls.c if they cant survive a majority vote of professional developers. Linux distributions have no say over what transpires in the source code. I never understood Linux's popularity over BSD. I've always attributed it to a naive reading of the GPL which seems to draw in all the l33t anarchists. No one I (_I_) know with experience of either prefers Linux to FreeBSD.
so if I'm writing Joeblowedit and I check my xml based config file I've *still* got to do some sanity checking.
Yes, for complex configuration files that is so. Hell, always get a second opinion of your data, check the sanity of all input regardless of its source or complexity.
writing part of a config parser is harder than writing a full parser.......
Well, not in this case. You simply traverse a tree and sanity check interesting nodes. No parsing.
It can be done (quite easily with small files, but your talking a "Windows Registry" like situation)
No one is advocating a Windows Registry situation. We're saying
/etc/xml.d/app1/conf.xml
/etc/xml.d/app2/conf.xml
The vast majority of those xml files will be dead simple, without associated DTDs. Some will be more complex but hardly more complex than sendmail.conf or named.conf. I mean, come on. The XML spec, grammar and examples, is a single document 1/10th the size of the page you are reading. Sendmail.conf requires the bat book, in reality bible.
Also, a curses based xml editor can be very small - as small as vi, easily. Such an editor would obviate the need for any xml knowledge.
Vast changes to programs required,
Yep. But its a given that more and more new code will use an xml parser. Windows didnt have a problem when it moved to the registry and an xml "registry" for linux is a much saner, much more attractive model for developers. It'll happen sooner rather than later.
The disadvantage is of course the verbosity and the supposed editing difficulty (although anyone one who can make an HTML page shouldn't have any real trouble with XML in their text editor, not to mention that it can be validated, so you'll know when you screwed up before your program goes freaky).
You wont have to edit xml by hand. You can edit it in an xml editor which displays the tree for an xml document - markup, content, and comments. It will be driven by a xml parser and it will be capable of displaying any and every xml file you care to throw at it. Do a search for merlot, swish, XMLEditor. Marvel at the screen shots.
So its not a clear Win-Win, obviously.
It would be if the only objection was the one you raised.
But let's be realistic here -- the argument isn't really about XML versus some non-XML alternative. The argument is about GUI'd admin tools and an newbie-friendly system versus the crusty ego and fat paychecks of unix wizardry.
This doesnt make sense. XML is a markup language that facilitates the transfer of information and its presentation. What's being transferred - in the unix world, anyway - will remain out the newbies reach just as it always has.
I'm only going to say this once - XML is *a* solution to the trivial problem of syntax;
XML is *the* general solution to the untrivial problem of *extensible* syntax. There are no other contenders waiting in the wings.
it does not, however, assault the intractable problems of semantics.
No shit. What configuration format does?
Your fantasy of trees magically passed between programs with no knowledge of each other falls down when you realize that each program assigns different meanings to each file/tree/whatever.
Fine. They should continue to do so. XML parsers dont interpret, they parse. The onus of interpretation lays upon the individual app writer. That's not going to change; we already knew computers werent thinking machines.
After 6 years of adminning systems, I feel more secure with each daemon checking their config files than passing it onto an independent parser daemon.
Really? Do you also think compilers are the work of the devil? Do you hand assemble source code into binary 1's and 0's?
Each program gets to test once with the parser code inside the program; if you move parsing out then you move that work onto the sysadmin (or home user) - the world is filled with minor API changes that screw you over.
Nonsense. The app defines the xml, the parser parses that xml and the app interprets the results. People dont write a compiler to compile their source, why should they write a parser? Given a well defined schema, I would much sooner trust an xml parser than I would a hand rolled parser.
I dont understand what api changes you are refering to. If XML changes, you rewrite your xml file, not your app and you upgrade your system's parser without dropping the older version. There are several versions of ncurses on my machine, for example. This sounds like a red herring. Already XML is far more standard than the unix api.
I dont think you quite understand what xml is.
I think it's because XML is not relevant for most of our [Linux's] problems.
I'm sorry, XML is here to stay and for good reason. It will become manifest in everything from docs to configuration files. There's nothing to debate.
(1) Apache wont beat MS Exchange. Neither will qmail, sendmail or postfix for that matter.
(2) As long as Linux programmers ensure that windows apps run on Linux, Bill will simply collect more money and spend that much less on developers. Duh.
(3) Bill G. doesnt preach, Bill G. gets things done. (Except Wine. Linux programmers get that one done for him.) Linuxbots preach.
Because most apps arent helloworld.c. Most apps have nested, tree like structures for preserving data and options between invocations. Because an XML standard is just that, a standard that can be interchanged between distributions, can be displayed on a web browser with suitable formatting, the list is as endless as the imagination.
Certainly you can do all this with your proposed format, but why on earth would you want to? No one else with a clue is.
1) XML parser API could be added so all modules will not have to create thier own.
I really like this idea. All the software I write nowadays uses XML for configuration. However, there are a few problems:
(1) This is a distribution and userland issue, not a kernel (Linux proper) issue. There's a lot of developers in userland and you cant mandate their whosale migration to XML anymore than you can herd cats.
This is where the Windows registry is superior to/etc,/usr/local/etc/home/hemos/etc. The higher lever of abstraction permits the registry structure to change without affecting installed software. (Hopefully MS will change it from a binary to an XML format. Hello, MS?) You dont parse configuration files in Windows, you simply register "stuff" to be read back later - Windows does all the real work for you. I think.
(2) Its often _much_ easier to bang out a customized config file parser than it is to write something to interpret the output of an xml parser (I use the expat streaming parser because tree parsers are comparatively much bigger and slower. YMMV.) So while you've standardized on a config file format, you _still_ have to write functions to interpret it. There are config files and then there are CONFIG files, if you know what I mean.
In conclusion, XML is a good thing, but not necessarily sliced bread for _developers_. In order to get programmers to adopt it for their apps, Linux will need to offer some sort of registry api based on XML. Not a difficult thing to do but obviously something that will be extremely useful.
This kind of structure can quickly become large, complex and slow to navigate ("windows is checking installed software," anyone?) so its probably a good idea to have a registry daemon start on boot.
The windows registry of course contains a lot more than config data for userland programs. I'm not as sure that that's such a good idea,
You appear to have little insight into either Linux or W2K. Furthermore, this topic is about Linux and not your experience with W2K. One of the biggest problems with Linux is that its advocates spend more time FUDding the competition than honestly appraising the work they advocate. As a result, people like Linus can whatever well meaning damage they want without raising a serious challenge.
REPEAT: The question is what does the future hold for linux, not Wolenczak's impression of W2K. W2K works very well with or without Wolenczak, thank you very much. Linux doesnt. What are we going to do about it?
At the top of my wish list for Linux is: slaughter all the sheep in the fold and give Linus the proverbial watch.
(Not picking on you specifically, btw, just the knee jerk W2K sux reaction that's typical in the Linux camp.)
First of all, the reason it's not in CVS is so that the code base can be controled.
Excuse me? Most people use CVS precisely because it offers control over large projects.
So some evil hax0r from Microsoft can't go and make it mutate like their ads in germany clame that linux will do.
You dont know what CVS is, do you?
Besides that, The decision is up to Linus, If he wants to move it into CVS, thats his choice, but I think it would be a bad idea.
Version control is not a bad idea. Linus is a bad idea. Version control is sound engineering practice. Patches are to version control as the abacus is to a scientific, plotting calculator. End of story.
Please read Eric Raymond's extremely accurate assesment of Linus' formal engineering skills. As good as he is, Linus is retarding Linux's development. And it is starting to show, W2K or no W2K. The Linux development model is complete bullshit and needs - desperately needs - to move to the BSD model. This benevolent dictator mythology has got to go.
The days of "hacking" an OS are over and the sooner we bid them good riddance, the better.
No company willing to shell out that much money for a domain name will ever buy.biz .
Wrong. Companies which consist of something more than hype will _LOVE_.biz. You know, a place for buyers and sellers to do business and to look for business without an endless stream of fuckedcompanies.com getting in the way. B2B sites. Serious career classified sites. Music archives for people who dont mind paying and can do without 10 banners/page, thank you very much. If the barrier to entry in.biz for Venusian Crystals and Vitamins, Inc. is too high, the world is a better place. The new tlds will improve the internet. The only people icann is disappointing are the idiot opportunists who ruined the.com space to begin with.
See, no one needs a dozen new.com's. One is enough. Why two? Are we all out of.com prefixes? Has Joe Pr0n out of words or something? Last I checked fatchickswithstringytits.com wasnt taken. Neither was naked-30yr-old-teens.com. I'm sure there are others.
You know, I expected icann to go the other way and pander to rampant commercialism. Instead, they've gone the other way. This is a good thing. All of you out there who were using the net before W95 came out, before it became a rage, before it was coopted by this maddening surge in venal pop culture, all of you will undoubtedly remember it to be a better place.
You want art?.museum. You want to see Ingrid's photoshop accidents?.com. You want accurate information about any number of professions from law to medicine to engineering?.pro. You want to learn how to duct tape your ide cables?.com
You get the picture.
This is neither elitism the raving of a crotchety curmudgeon. This is, finally, an injection of fairness into the internet. I turned off the boob tube a long time ago. I dont want to have to yank the cable modem too.
If almost no one is allowed to use them, the general consumer will likely be unaware that they exist, and continue in their.com'ocentric mindset.
Good. Excellent. The consumer can go watch tv, surf a few pr0n sites, www.nextlamehollywoodmovie.com and then maybe (probably) land on a site giving him the chance to WIN 1,000,000$ BY FILLING OUT OUR SURVEY!
.com already has that covered. Now, what about the rest of us? Are we doomed to look for needles in the.com haystack? Fuck the consumer. Icann is doing the correct thing.
This isnt insightful, this is idiotic. They may seem wrong to _you_ but that's only because you have neither the capacity to invent anything, nor the capacity to think intellectually about something that doesnt lie immediately before your nose.
Patents are meant to protect the inventor against pilfering (usually much bigger) competitors. If MegaCorp Inc. wants to make use of Joe Bloe's process of extracting logic from/. morons, then MegaCorp Inc. has to pay Joe Bloe. If you find this unacceptable, be prepared to live in a society where the only technological innovation is MegaCorp's self interested, self serving inventions.
Nothing is perfect but as it stands today, patents remain the single proven method for introducing competitive ideas into society. In fact, merely the fact that someone holds a patent on something is inducement for someone else to come up with something better. Until you come up with something better, "patents are wrong right down to the concept" is moronic drivel.
If RAMBUS can demonstrate their claims, then RAMBUS _should_ be awarded royalties. Why the fuck not? Are you such a fan of intel/nvidia/whatever that you believe they should get that money instead? I personally dont care where the money goes but I feel a lot better if _all_ deserving parties get their share.
Slashdot Mirror
Understand what this means. Mathematically, inconvertibly so, the presidency was won on a coin toss.
50% +1 is a quaint holdover from times past. We have long surpassed its capacity for accuracy. You cant exactly announce to 100,000,000 million people "all for Bush say aye. All for Gore, nay. Ok, the ayes have it." Well, you can and you do but you also hope that the result is statistically significant.
It wasnt this time. Not by a long shot.
Truly a remarkable event. I'll leave to someone else to ponder out loud what the chances of such an event occuring were in the first place
--
The BSD license allows for closed licensing around the licensed code. Releasing something under the BSD license is tacitly approving of such a thing. I'm not saying that's bad, nor, I think, did the original poster. It's just that you do accept that, and you have to in turn accept the concequences
That is absolutely acceptable to BSD advocates.
That is, you will have to accept the fact that Microsoft is going to use your code and never contribute back.
I have no problem with that. If they use the better code, the world is that much better off for it. My hatred for MS buys me nothing - especially if I have to use their product for one reason or another (choice included.) If they have the resources to maintain an independent fork, bully for them. The original code remains under continued OSS development.
Best of both worlds as far as I can see.
(I dont understand where I introduced a strawman in my original arguement. I maintain that the standard GPL relicensing arguement is entirely based on one big strawman, actually.)
--
--
-- Your boss.
--
[*] "I'll read this later, there's still a few more links to follow," kind of thing. Its hard to absorb good information off the web, isnt it? How many of you have read 1/100th of your book marked pages? Not many, I bet. I've often found myself spending more time gathering links than actually reading the information I originally sought.
--
Good riddance.
--
But seriously, that would be a cool party trick.
--
There is no reason not to open source the kernel because no one writes to the kernel. (Even NT apps are almost all entirely Win32, an api on top of the NT kernel.) It doesnt matter whether its open source or not. The OS X, api's are another matter entirely, however. They may not be able to keep a lid under posix, but they as hell can - AND WILL - keep carbon and all the other apis strictly proprietary.
Again, something no one programs directly is a free lunch.
--
Why use Darwin when you can use FreeBSD.
Or windows, or BeOS or CP/M. Darwin has a microkernel, FreeBSD does not. That itself makes it an object of interest, at least. Linus notwithstanding, a kernel hacker can lear a lot from running darwin.
X had Aqua so there is a reason to use it.
X has Aqua, does it? Here, pull my finger.
Why develop software for Apple to get rich on and get nothing in return?
Why develop software for RedHat, Corel, Caldera, etc and get nothing in return? OSS software is OSS software. Deal with it. (Not that you, personally, would develop anything other toner smudges on your fingers.)
Do I look stoopid?
Well, you arent entirely the brightest bulb on the christmas tree.
--
If you think this is meaningless, if you think this is of no use, you are welcome to uninstall libxml from your machine, write a parser for every program you develop, and have it promptly ignored by the general community.
Its your call. Personally, the one thing I enjoy less than UI code is code to translate and interchange data between apps and systems. XML solves that problem and allows me that much more time to be productive or goof off.
--
--
No, it cant. You'd need to merge DEVELOPMENT of kernel AND userland software for that to happen in any remotely effective manner. FreeBSD isnt a distribution in the sense Linux users understand. Even 3rd party ports have a structure imposed upon them. Their sources, when installed, all live under a single directory structure which is readily grokked and upgradeable.
This is Linux's biggest failing, for me, that it is merely a kernel There is a distinct lack of cohesion that simply _cannot_ be addressed by any distribution. Performance issues are a wash. Sometimes FreeBSD is faster, sometimes Linux. The numbers never justify any crowing, though.
The cohesion extends into policy, as well. Changes arent committed to ls.c if they cant survive a majority vote of professional developers. Linux distributions have no say over what transpires in the source code. I never understood Linux's popularity over BSD. I've always attributed it to a naive reading of the GPL which seems to draw in all the l33t anarchists. No one I (_I_) know with experience of either prefers Linux to FreeBSD.
--
--
so if I'm writing Joeblowedit and I check my xml based config file I've *still* got to do some sanity checking.
Yes, for complex configuration files that is so. Hell, always get a second opinion of your data, check the sanity of all input regardless of its source or complexity.
writing part of a config parser is harder than writing a full parser.......
Well, not in this case. You simply traverse a tree and sanity check interesting nodes. No parsing.
It can be done (quite easily with small files, but your talking a "Windows Registry" like situation)
No one is advocating a Windows Registry situation. We're saying
/etc/xml.d/app1/conf.xml
/etc/xml.d/app2/conf.xml
The vast majority of those xml files will be dead simple, without associated DTDs. Some will be more complex but hardly more complex than sendmail.conf or named.conf. I mean, come on. The XML spec, grammar and examples, is a single document 1/10th the size of the page you are reading. Sendmail.conf requires the bat book, in reality bible.
Also, a curses based xml editor can be very small - as small as vi, easily. Such an editor would obviate the need for any xml knowledge.
Vast changes to programs required,
Yep. But its a given that more and more new code will use an xml parser. Windows didnt have a problem when it moved to the registry and an xml "registry" for linux is a much saner, much more attractive model for developers. It'll happen sooner rather than later.
--
You wont have to edit xml by hand. You can edit it in an xml editor which displays the tree for an xml document - markup, content, and comments. It will be driven by a xml parser and it will be capable of displaying any and every xml file you care to throw at it. Do a search for merlot, swish, XMLEditor. Marvel at the screen shots.
So its not a clear Win-Win, obviously.
It would be if the only objection was the one you raised.
But let's be realistic here -- the argument isn't really about XML versus some non-XML alternative. The argument is about GUI'd admin tools and an newbie-friendly system versus the crusty ego and fat paychecks of unix wizardry.
This doesnt make sense. XML is a markup language that facilitates the transfer of information and its presentation. What's being transferred - in the unix world, anyway - will remain out the newbies reach just as it always has.
--
XML is *the* general solution to the untrivial problem of *extensible* syntax. There are no other contenders waiting in the wings.
it does not, however, assault the intractable problems of semantics.
No shit. What configuration format does?
Your fantasy of trees magically passed between programs with no knowledge of each other falls down when you realize that each program assigns different meanings to each file/tree/whatever.
Fine. They should continue to do so. XML parsers dont interpret, they parse. The onus of interpretation lays upon the individual app writer. That's not going to change; we already knew computers werent thinking machines.
After 6 years of adminning systems, I feel more secure with each daemon checking their config files than passing it onto an independent parser daemon.
Really? Do you also think compilers are the work of the devil? Do you hand assemble source code into binary 1's and 0's?
Each program gets to test once with the parser code inside the program; if you move parsing out then you move that work onto the sysadmin (or home user) - the world is filled with minor API changes that screw you over.
Nonsense. The app defines the xml, the parser parses that xml and the app interprets the results. People dont write a compiler to compile their source, why should they write a parser? Given a well defined schema, I would much sooner trust an xml parser than I would a hand rolled parser.
I dont understand what api changes you are refering to. If XML changes, you rewrite your xml file, not your app and you upgrade your system's parser without dropping the older version. There are several versions of ncurses on my machine, for example. This sounds like a red herring. Already XML is far more standard than the unix api.
I dont think you quite understand what xml is.
I think it's because XML is not relevant for most of our [Linux's] problems.
I'm sorry, XML is here to stay and for good reason. It will become manifest in everything from docs to configuration files. There's nothing to debate.
--
--
(2) As long as Linux programmers ensure that windows apps run on Linux, Bill will simply collect more money and spend that much less on developers. Duh.
(3) Bill G. doesnt preach, Bill G. gets things done. (Except Wine. Linux programmers get that one done for him.) Linuxbots preach.
--
# this is a comment
keyword=setting
Because most apps arent helloworld.c. Most apps have nested, tree like structures for preserving data and options between invocations. Because an XML standard is just that, a standard that can be interchanged between distributions, can be displayed on a web browser with suitable formatting, the list is as endless as the imagination.
Certainly you can do all this with your proposed format, but why on earth would you want to? No one else with a clue is.
--
I really like this idea. All the software I write nowadays uses XML for configuration. However, there are a few problems:
(1) This is a distribution and userland issue, not a kernel (Linux proper) issue. There's a lot of developers in userland and you cant mandate their whosale migration to XML anymore than you can herd cats.
This is where the Windows registry is superior to
(2) Its often _much_ easier to bang out a customized config file parser than it is to write something to interpret the output of an xml parser (I use the expat streaming parser because tree parsers are comparatively much bigger and slower. YMMV.) So while you've standardized on a config file format, you _still_ have to write functions to interpret it. There are config files and then there are CONFIG files, if you know what I mean.
In conclusion, XML is a good thing, but not necessarily sliced bread for _developers_. In order to get programmers to adopt it for their apps, Linux will need to offer some sort of registry api based on XML. Not a difficult thing to do but obviously something that will be extremely useful.
host +
|
+ user1 +
| |
| app1 +
| |
| foo bar parameter
| |
| etc, etc
|
sendmail, etc, etc
This kind of structure can quickly become large, complex and slow to navigate ("windows is checking installed software," anyone?) so its probably a good idea to have a registry daemon start on boot.
The windows registry of course contains a lot more than config data for userland programs. I'm not as sure that that's such a good idea,
--
REPEAT: The question is what does the future hold for linux, not Wolenczak's impression of W2K. W2K works very well with or without Wolenczak, thank you very much. Linux doesnt. What are we going to do about it?
At the top of my wish list for Linux is: slaughter all the sheep in the fold and give Linus the proverbial watch.
(Not picking on you specifically, btw, just the knee jerk W2K sux reaction that's typical in the Linux camp.)
--
Excuse me? Most people use CVS precisely because it offers control over large projects.
So some evil hax0r from Microsoft can't go and make it mutate like their ads in germany clame that linux will do.
You dont know what CVS is, do you?
Besides that, The decision is up to Linus, If he wants to move it into CVS, thats his choice, but I think it would be a bad idea.
Version control is not a bad idea. Linus is a bad idea. Version control is sound engineering practice. Patches are to version control as the abacus is to a scientific, plotting calculator. End of story.
Please read Eric Raymond's extremely accurate assesment of Linus' formal engineering skills. As good as he is, Linus is retarding Linux's development. And it is starting to show, W2K or no W2K. The Linux development model is complete bullshit and needs - desperately needs - to move to the BSD model. This benevolent dictator mythology has got to go.
The days of "hacking" an OS are over and the sooner we bid them good riddance, the better.
--
Wrong. Companies which consist of something more than hype will _LOVE_
See, no one needs a dozen new
You know, I expected icann to go the other way and pander to rampant commercialism. Instead, they've gone the other way. This is a good thing. All of you out there who were using the net before W95 came out, before it became a rage, before it was coopted by this maddening surge in venal pop culture, all of you will undoubtedly remember it to be a better place.
You want art?
You get the picture.
This is neither elitism the raving of a crotchety curmudgeon. This is, finally, an injection of fairness into the internet. I turned off the boob tube a long time ago. I dont want to have to yank the cable modem too.
--
Huh? I certainly hope not. One
If almost no one is allowed to use them, the general consumer will likely be unaware that they exist, and continue in their
Good. Excellent. The consumer can go watch tv, surf a few pr0n sites, www.nextlamehollywoodmovie.com and then maybe (probably) land on a site giving him the chance to WIN 1,000,000$ BY FILLING OUT OUR SURVEY!
.com already has that covered. Now, what about the rest of us? Are we doomed to look for needles in the
--
Patents are meant to protect the inventor against pilfering (usually much bigger) competitors. If MegaCorp Inc. wants to make use of Joe Bloe's process of extracting logic from
Nothing is perfect but as it stands today, patents remain the single proven method for introducing competitive ideas into society. In fact, merely the fact that someone holds a patent on something is inducement for someone else to come up with something better. Until you come up with something better, "patents are wrong right down to the concept" is moronic drivel.
If RAMBUS can demonstrate their claims, then RAMBUS _should_ be awarded royalties. Why the fuck not? Are you such a fan of intel/nvidia/whatever that you believe they should get that money instead? I personally dont care where the money goes but I feel a lot better if _all_ deserving parties get their share.
--