Oh bullshit. If it weren't for the outsized (and rather fragile) egos of many hackers, the free software community, if it were to exist at all, would be a much duller (and certainly more "corporate") environment.
Are you seriously suggesting that everyone out there who wants to create a free desktop UI should work together in some grand compromise? Why? Faster time to market? To compete with microsoft?
These are *business* goals. If you *really* want to build a better mousetrap, you ought to forget about them. So GNOME and Enlightenment don't proceed as fast as they would otherwise... At least each will proceed in the direction proper to each -- and not conflate each other's goals in some awkward manner.
This is the biggest wank-fest I've seen in ages -- everyone shouting as loudly as possible: "Not UNIX! UNIX *can't* DIE! It's too flexible! Too modular!"
Okay: is everyone done? Good.
Clearly, UNIX isn't going anywhere *soon*. This is simply inarguable.
But it "can never die"? It's somewhat shocking (and certainly depressing) that it hasn't already died. The OS is over thirty years old. Yeah, UNIX is a durable design. Sure. But the fact that it hasn't been replaced by something better -- in three decades -- is more a sign of businesses' reluctance to change than it is a sign of UNIX's perfection. The computer industry is absurdly conservative. The fact that people still use COBOL -- not to mention C (geez, now I'm gonna get it, aren't I) -- is evidence enough of that.
The fact is: the technology has improved. But we still use the same old tools, because it takes way too long for this stuff to move from academia into the mainstream.
You think UNIX is an ideal OS design? You're fooling yourselves. And don't tell me: "It's better than Windows! It's better than MacOS!" I know it is (well, the new MacOS *is* a UNIX flavor). That isn't the point. Why should an OS even be *susceptible* to buffer overflows? Why should it need a call like setuid(2)?
When your hammer is C++, everything begins to look like a thumb. -- Steve Hoflich on comp.lang.c++
As nasty and tasteless as Tcl is, it is a positive dream compared to Perl...Perl 5 does indeed offer 1000 times the syntactic complexity of Common Lisp, 10 times the semantic complexity of Common Lisp, and 1/10th the power of Fortran II. -- Philip Greenspun
Greenspun's Tenth Rule of Programming: ``Any sufficiently-complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp.''
High end consumer digital cameras are currently in the range of 1800x1200 pixels, and they produce quite satisfactory non-critical prints.
Non-critical? Do you imagine that filmmakers consider their frames to be non-critical?
Take a look, sometime, at Chris Marker's "La Jetté." All but a couple of seconds of this film are composed of still shots.
The point is: I would notice the difference, just as you notice the difference when you use your digital camera. Some people take film rather seriously.
Are you saying that one could use film as a digital medium? (I don't think this is what you're saying, but I'm unsure.) In that case, you would have the exact same problem you have with RAM/disk space: you'd need enormous amounts of film stock -- truly unwieldly amounts.
But, if you mean that one could record the movie using some very high resolution digital scheme and then convert the frames to actual analog film...well, it's interesting, but there are two issues:
1. The filmmaker still needs absurd, expensive amounts of digital storage. 2. The D-A conversion has to be superb, otherwise there is no point to it. And (good) D-A conversion is hard.
But compression which loses information degrades quality. This is preceisely what you're trying to avoid.
Everyone is led astray by how much better digital video is than analog video. It is much better. But it's markedly inferior to film. Your DVD copy of movie X looks better than your VHS copy, no doubt. But the DVD is still using a compression algorithm which loses information, and if you were to project it on a big screen and compare it to the film version, you'd notice the difference right away.
The CGI effects were sharper but I couldn't say that any of the live action looked better.
I'd be surprised if the live action didn't look worse. Of course, it depends on how it was originally filmed, but the resolution of film is considerably higher than any digital video system in use today.
Digital video has crap resolution. Why? Because to achieve the same sort of resolution you get with film, you need to store enormous amounts of data.
You can't afford the required amount of memory/storage. So you use compression.
Which means you lose quality (because you certainly aren't using *lossless* compression -- not when you need huge compression ratios), which was what you were trying to gain in the first place.
Until multi-terabyte storage is fast, cheap, and small, film will continue to be superior. As is so clearly is now.
But this page is going to end up being 99.6% your comments and 0.4% my posting, so I think the system tends to converge on some sort of objectivity.
Yes, yes, but in that "system" it has already been decided upon that your business affiliations, ESR's newfound wealth, and whatever else are worthy of discussion.
People will post here, both supporting and defending your decision to take a job without asking themselves why they care at all. You will be accused of shameless self-promotion by people whose very discussion of you only serves to promote you more.
The media is powerful, and people can be very stupid, indeed.
There were two points. The parodical post addressed neither effectively.
1) The Linux kernel is not standardized. At best, this is false; at worst, it is nonsensical. As I wrote, Linux is a partial implementation of a standard -- one which existed even before Linux did. It makes little to no sense to talk of standardizing Linux itself.
2) The Linux kernel is in the control of one person. True. But totally irrelevant to a discussion of standardization. Of course, I guess that might have been the original poster's point. Kudos to him/her in that case.
Do you think that ANSI is in charge of gcc? or Solaris cc? or TRU64 cc?
I assure you, it is not. The fact that an *implementation* of a standard is controlled by a small group of people (or even by a single person) still does not affect the fact that it IS an implementation of a standard.
Linus controls the implementation of Linux. But he follows the POSIX standard in doing so. (Not completely, but almost no Unixes do, for very good reason.)
I think you have some good ideas -- and some really bizarre ones...
Parameteric polymorphism and async IO are must-haves. No question.
First-class functions are NOT. Why? Because they just don't belong in the OO paradigm. You can still get the same effect by using interfaces and a "strategy" design pattern. I'm not an OO zealot, by any means, but I don't particulary enjoy mixing programming metaphors, either.
Using goto to perform efficient tail recursion is brain dead. You must be kidding. Use Scheme.
How do you propose testing whether or not you will get a lock immediately? Unless you actually GET a lock, the test is meaningless; some other thread might ask for the same lock between the time you test and the time you acquire.
But, you're right that Java isn't a modern language. No language in widespread use is. I wish more people would use SML, but most programmers are just too damn stupid.
Slashdot Mirror
Try this:
Delete glibc.
I am fast becoming OOG's number-one fan.
Oh bullshit. If it weren't for the outsized (and rather fragile) egos of many hackers, the free software community, if it were to exist at all, would be a much duller (and certainly more "corporate") environment.
Are you seriously suggesting that everyone out there who wants to create a free desktop UI should work together in some grand compromise? Why? Faster time to market? To compete with microsoft?
These are *business* goals. If you *really* want to build a better mousetrap, you ought to forget about them. So GNOME and Enlightenment don't proceed as fast as they would otherwise... At least each will proceed in the direction proper to each -- and not conflate each other's goals in some awkward manner.
Dude -- you just got your ass kicked (or your head broken, I suppose) by a neanderthal troll.
And he's *right*, too.
You haven't been paying attention, have you?
As with anything modeled after MS products, it is feature-rich enough to do both simultaneously!
What the hell do you call DARPA?
This is the biggest wank-fest I've seen in ages -- everyone shouting as loudly as possible: "Not UNIX! UNIX *can't* DIE! It's too flexible! Too modular!"
Okay: is everyone done? Good.
Clearly, UNIX isn't going anywhere *soon*. This is simply inarguable.
But it "can never die"? It's somewhat shocking (and certainly depressing) that it hasn't already died. The OS is over thirty years old. Yeah, UNIX is a durable design. Sure. But the fact that it hasn't been replaced by something better -- in three decades -- is more a sign of businesses' reluctance to change than it is a sign of UNIX's perfection. The computer industry is absurdly conservative. The fact that people still use COBOL -- not to mention C (geez, now I'm gonna get it, aren't I) -- is evidence enough of that.
The fact is: the technology has improved. But we still use the same old tools, because it takes way too long for this stuff to move from academia into the mainstream.
You think UNIX is an ideal OS design? You're fooling yourselves. And don't tell me: "It's better than Windows! It's better than MacOS!" I know it is (well, the new MacOS *is* a UNIX flavor). That isn't the point. Why should an OS even be *susceptible* to buffer overflows? Why should it need a call like setuid(2)?
You ought to be *hoping* that UNIX dies.
When your hammer is C++, everything begins to look like a thumb.
-- Steve Hoflich on comp.lang.c++
As nasty and tasteless as Tcl is, it is a positive dream compared to Perl...Perl 5 does indeed offer 1000 times the syntactic complexity of Common Lisp, 10 times the semantic complexity of Common Lisp, and 1/10th the power of Fortran II.
-- Philip Greenspun
Greenspun's Tenth Rule of Programming: ``Any sufficiently-complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp.''
-jaz
You also would never mistake it for a photographic image of the real world. Unless you were legally blind.
Also, the new film technology that Ebert wrote about eliminates jitter -- so there goes the bulk of your argument.
Ultimately, though, I think you're right that the masses won't care. It's just very unfortunate.
Take a look, sometime, at Chris Marker's "La Jetté." All but a couple of seconds of this film are composed of still shots.
The point is: I would notice the difference, just as you notice the difference when you use your digital camera. Some people take film rather seriously.
Are you saying that one could use film as a digital medium? (I don't think this is what you're saying, but I'm unsure.) In that case, you would have the exact same problem you have with RAM/disk space: you'd need enormous amounts of film stock -- truly unwieldly amounts.
But, if you mean that one could record the movie using some very high resolution digital scheme and then convert the frames to actual analog film...well, it's interesting, but there are two issues:
1. The filmmaker still needs absurd, expensive amounts of digital storage.
2. The D-A conversion has to be superb, otherwise there is no point to it. And (good) D-A conversion is hard.
Film's resolution is considerably higher than HDTV's. This post is just plain false.
Everyone is led astray by how much better digital video is than analog video. It is much better. But it's markedly inferior to film. Your DVD copy of movie X looks better than your VHS copy, no doubt. But the DVD is still using a compression algorithm which loses information, and if you were to project it on a big screen and compare it to the film version, you'd notice the difference right away.
Digital video has crap resolution. Why? Because to achieve the same sort of resolution you get with film, you need to store enormous amounts of data.
You can't afford the required amount of memory/storage. So you use compression.
Which means you lose quality (because you certainly aren't using *lossless* compression -- not when you need huge compression ratios), which was what you were trying to gain in the first place.
Until multi-terabyte storage is fast, cheap, and small, film will continue to be superior. As is so clearly is now.
People will post here, both supporting and defending your decision to take a job without asking themselves why they care at all. You will be accused of shameless self-promotion by people whose very discussion of you only serves to promote you more.
The media is powerful, and people can be very stupid, indeed.
There were two points. The parodical post addressed neither effectively.
1) The Linux kernel is not standardized. At best, this is false; at worst, it is nonsensical. As I wrote, Linux is a partial implementation of a standard -- one which existed even before Linux did. It makes little to no sense to talk of standardizing Linux itself.
2) The Linux kernel is in the control of one person. True. But totally irrelevant to a discussion of standardization. Of course, I guess that might have been the original poster's point. Kudos to him/her in that case.
How is this a response to what I wrote?
It's a complete non sequiter.
----------
Do you think that ANSI is in charge of gcc? or Solaris cc? or TRU64 cc?
I assure you, it is not. The fact that an *implementation* of a standard is controlled by a small group of people (or even by a single person) still does not affect the fact that it IS an implementation of a standard.
Linus controls the implementation of Linux. But he follows the POSIX standard in doing so. (Not completely, but almost no Unixes do, for very good reason.)
I think you have some good ideas -- and some really bizarre ones...
Parameteric polymorphism and async IO are must-haves. No question.
First-class functions are NOT. Why? Because they just don't belong in the OO paradigm. You can still get the same effect by using interfaces and a "strategy" design pattern. I'm not an OO zealot, by any means, but I don't particulary enjoy mixing programming metaphors, either.
Using goto to perform efficient tail recursion is brain dead. You must be kidding. Use Scheme.
How do you propose testing whether or not you will get a lock immediately? Unless you actually GET a lock, the test is meaningless; some other thread might ask for the same lock between the time you test and the time you acquire.
But, you're right that Java isn't a modern language. No language in widespread use is. I wish more people would use SML, but most programmers are just too damn stupid.
You think you're being clever, don't you?
Linux is a (partial) implementation of the POSIX standard. Like every other Unix in the world.
Nice try.