... the news made it into the online version of the Austrian daily newspaper "Der Standard", which is one of the most popular web sites in Austria (2nd at the moment, I think). The headline was "Top-Programmer leaves Red Hat".:-) It concludes that the "commercialization" of Linux would cause more reactions like this among open source programmers... (look here). I don't think it's bad to have an exact Windows clone personality for Linux, if it's also more flexible than Windows. There'll always be room for creativity, since everyone's free to change/improve whatever desktop/window manager/variation of Linux they begin with.
Again, since this is a catch-22 situation (some people will keep using Windows for the games, and games will be made mostly for Windows as long as most people keep sticking to Windows) it'd make sense to support WINE as much as possible, in order to make some games playable under Linux. If more people can then keep using Linux for their favourite games instead of using a dual-boot setup for the occasional game break, and if game publishers start getting questions about using the games under WINE (OK, that's a bit far-fetched), they might consider better support for Linux... In any case, WINE is a good effort and those purists who shun it are those who'd rather keep Linux in a niche.
That is a good idea - Usenet is dying because it can't cope with new developments in the quickly evolving Internet, such as spam. It's time for something new.
One of the strengths of the Usenet was its distributed design, making it suitable for non-persistant links. Today, I'd say that the cost of running a news server with all the binaries groups outweighs the gain from this design, since most sites who could afford a full newsserver have very good links. A cacheing nntpd is much more useful than a full-blown newsserver these days, except for very large ISPs (IMHO).
Web communities with forums are already evolving nicely, and it seems like they will replace Usenet eventually (except for some die-hards, who still insist on using text consoles and low-bandwidth connections and will do so for the next 10 years; no offense intended).
Note that many Internet users who haven't been around for many years aren't very familiar with Usenet anyway, they'll just go looking for stuff on the web instead.
There is no reason why any system would necessarily have to crash under heavy load, it should just become slower. Anything that does cause a system to crash under the./-effect should be fixed. Isn't this just a lovely torture-test that can be very useful in determining whether a system works reliably or not?
I propose the following as a fair benchmark for web servers:
Every day,./ chooses a web server on the internet at random. It then presents a link to that server somewhere on the start page, calling it the "benchmark link" or whatever (so people know what it's for). It is then./-ed by the readers, and at the same time monitored for its uptime. Its server OS and software are determined (if possible, should be) and as the days pass, statistics are put together for the average time a server OS lasted under that strain.
Not entirely serious, but a good "real world" benchmark, and I'd enjoy that.
I would compile the non-GNU shell with lcc and use the newlib C library (which is BSD-licensed). Termcap is even easier (from BSD).
Don't be so ignorant - the GNU tools were handy, but not necessary, as NetBSD/FreeBSD proved (except gcc for the kernel, but if it hadn't been available, something else would have been used).
Just because Linux was GPL-friendly from the beginning, it doesn't mean that it wouldn't exist without GPL'ed software.
AFAIK, Intel binary support is available only in the *Intel* ports of *BSD. There is *no* way to run Linux/Intel binaries under *BSD/Alpha, and even if there was one (like an em86 port to *BSD), it would be slower than native binaries.
Microsoft is apparently porting applications such as IE and Outlook to Unix, so they can add proprietary extensions to various internet protocols (or implement completely new variants) with a good chance of gaining market share by being the only vendor supporting and providing these protocols. It's the old game, but because of the momentum Linux has gained, playing it in the Wintel world isn't sufficient anymore.
A fair way to pitch OSes, hardware and server software against each other would be some sort of "tuning competition" (i.e. the Formula 1 of computing, but not quite). With several disciplines such as static/dynamic web serving, file serving, scientific computing (with well-defined tasks) and several price ranges for the total system cost, it'd be interesting to see how things turn out. After all, the benchmarks performed by magazines and those paid by vendors who try to make the competition look bad can never be fair, because the interest in tuning a particular platform is never high enough (and sometimes deliberately low).
Who has the guts to organize and/or sponsor such an event? Magazines would be welcome.
The W3C itself keeps failing to set practical, viable standards. Why does anyone pay attention to a self-appointed maker of so-called standards, if these standards are apparently produced out of thin air, without a proven concept or implementation? The more useful later releases of the HTML standard only made sense because there were already good implementations in the mainstream browsers of most of the new features. CSSn, while it does help site designers to some extent, is an utter failure because noone has managed to implement CSS1 fully until recently (if Mozilla in its present unreleased state counts at all...).
Standards should be drafted based on proven designs, not the other way round. Most RFC's are based on working code, why can't this be expected from the W3C?
Let's hope that XML/XSL turns out the be simple and consistent enough in practice to make up for some of the obscenities in web design that HTML + all the incompatible extensions have made necessary. (Allow me to be sceptical, since approximately 1 1/2 years have passed since the introduction of XML by the W3C and I don't see it being used much...)
Who says that they have no clue? I thought that they managed it very well to completely mis-tune the Linux system while not making it too obvious. Read this too and think about it. They claimed that they asked in newsgroups and mailing lists, but they did not mention in their report that they fine-tuned the file buffer, for example. I wonder how many manager-types "bought" this story. One can only hope that they'll install NT instead, pay far too much for the performance they'll get out of it, and never find out why other companies can operate better at a lower cost.:-)
Will the SDK support arbitrary resolutions and colour depths in fullscreen mode under X11? Any 3D graphics hardware support? Does anyone else think, there's still a long way to go till game SDK's for Linux are anywhere close to the point DirectX was 3-4 years ago on the PC?
Still waiting for GGI and reasonable support for switching resolutions and colour depths...
Considering the present state-of-the-art in Linux game SDK's, they did well though (then again, there were good cross-platform action games years ago)
I am continually astonished at the ability of good programmers to defend lazy design, lousy design, and plain-old bad coding by saying that users of their software must "know" various and sundry things about their software before they can use it "correctly."
Seconded! IMHO, this is the biggest threat to the proliferation of free/open source software: the inability of some of the programmers to react positively to criticism. Unfortunately, they often prefer leaving/dropping a project to improving it when the user's criticism is too harsh, so I'm not convinced that clueless users are necessarily good for projects such as Debian (then again, in some cases it might be better if projects which fail to respond to user criticism vanished altogether!).
It seems to me that in many cases, the developers/contributors of projects like Debian (and many other projects in the Linux world and beyond) are a bit too eager to respond to the difficulties novice users (which, IMHO, aren't necessarily stupid, often they just don't have enough time on their hands to track all the prerequisite information) have with their software by calling them "stupid". They should notice that user's problems are often a sign that something could be improved in the software, whether it's the GUI, the documentation, or general useability and act accordingly - i.e. improve their software with the users in mind instead of feeling insulted and acting defensively because someone didn't like their stuff or was unable to use it for some reason (which should be worth investigating!).
Slashdot Mirror
... now it would be nice if such bugs could be fixed in a running kernel without rebooting (using a more modular approach).
... the news made it into the online version of the Austrian daily newspaper "Der Standard", which is one of the most popular web sites in Austria (2nd at the moment, I think). The headline was "Top-Programmer leaves Red Hat". :-) It concludes that the "commercialization" of Linux would cause more reactions like this among open source programmers... (look here). I don't think it's bad to have an exact Windows clone personality for Linux, if it's also more flexible than Windows. There'll always be room for creativity, since everyone's free to change/improve whatever desktop/window manager/variation of Linux they begin with.
Again, since this is a catch-22 situation (some people will keep using Windows for the games, and games will be made mostly for Windows as long as most people keep sticking to Windows) it'd make sense to support WINE as much as possible, in order to make some games playable under Linux. If more people can then keep using Linux for their favourite games instead of using a dual-boot setup for the occasional game break, and if game publishers start getting questions about using the games under WINE (OK, that's a bit far-fetched), they might consider better support for Linux... In any case, WINE is a good effort and those purists who shun it are those who'd rather keep Linux in a niche.
One of the strengths of the Usenet was its distributed design, making it suitable for non-persistant links. Today, I'd say that the cost of running a news server with all the binaries groups outweighs the gain from this design, since most sites who could afford a full newsserver have very good links. A cacheing nntpd is much more useful than a full-blown newsserver these days, except for very large ISPs (IMHO).
Web communities with forums are already evolving nicely, and it seems like they will replace Usenet eventually (except for some die-hards, who still insist on using text consoles and low-bandwidth connections and will do so for the next 10 years; no offense intended).
Note that many Internet users who haven't been around for many years aren't very familiar with Usenet anyway, they'll just go looking for stuff on the web instead.
There is no reason why any system would necessarily have to crash under heavy load, it should just become slower. Anything that does cause a system to crash under the ./-effect should be fixed. Isn't this just a lovely torture-test that can be very useful in determining whether a system works reliably or not?
Every day, ./ chooses a web server on the internet at random. It then presents a link to that server somewhere on the start page, calling it the "benchmark link" or whatever (so people know what it's for). It is then ./-ed by the readers, and at the same time monitored for its uptime. Its server OS and software are determined (if possible, should be) and as the days pass, statistics are put together for the average time a server OS lasted under that strain.
Not entirely serious, but a good "real world" benchmark, and I'd enjoy that.
Don't be so ignorant - the GNU tools were handy, but not necessary, as NetBSD/FreeBSD proved (except gcc for the kernel, but if it hadn't been available, something else would have been used).
Just because Linux was GPL-friendly from the beginning, it doesn't mean that it wouldn't exist without GPL'ed software.
AFAIK, Intel binary support is available only in the *Intel* ports of *BSD. There is *no* way to run Linux/Intel binaries under *BSD/Alpha, and even if there was one (like an em86 port to *BSD), it would be slower than native binaries.
-LJ
Who has the guts to organize and/or sponsor such an event? Magazines would be welcome.
Standards should be drafted based on proven designs, not the other way round. Most RFC's are based on working code, why can't this be expected from the W3C?
Let's hope that XML/XSL turns out the be simple and consistent enough in practice to make up for some of the obscenities in web design that HTML + all the incompatible extensions have made necessary. (Allow me to be sceptical, since approximately 1 1/2 years have passed since the introduction of XML by the W3C and I don't see it being used much...)
Who says that they have no clue? I thought that they managed it very well to completely mis-tune the Linux system while not making it too obvious. Read this too and think about it. They claimed that they asked in newsgroups and mailing lists, but they did not mention in their report that they fine-tuned the file buffer, for example. I wonder how many manager-types "bought" this story. One can only hope that they'll install NT instead, pay far too much for the performance they'll get out of it, and never find out why other companies can operate better at a lower cost. :-)
Still waiting for GGI and reasonable support for switching resolutions and colour depths...
Considering the present state-of-the-art in Linux game SDK's, they did well though (then again, there were good cross-platform action games years ago)
Seconded! IMHO, this is the biggest threat to the proliferation of free/open source software: the inability of some of the programmers to react positively to criticism. Unfortunately, they often prefer leaving/dropping a project to improving it when the user's criticism is too harsh, so I'm not convinced that clueless users are necessarily good for projects such as Debian (then again, in some cases it might be better if projects which fail to respond to user criticism vanished altogether!).
It seems to me that in many cases, the developers/contributors of projects like Debian (and many other projects in the Linux world and beyond) are a bit too eager to respond to the difficulties novice users (which, IMHO, aren't necessarily stupid, often they just don't have enough time on their hands to track all the prerequisite information) have with their software by calling them "stupid". They should notice that user's problems are often a sign that something could be improved in the software, whether it's the GUI, the documentation, or general useability and act accordingly - i.e. improve their software with the users in mind instead of feeling insulted and acting defensively because someone didn't like their stuff or was unable to use it for some reason (which should be worth investigating!).