wow. in that diagram, the asteriod matilde is even bigger than the sun, even. I'm worried. They say that it won't hit the earth, but that's a big piece of rock...
...and here is evidence to this fact you point out.
And I'm contributing to it!
Actually, the internet is more useful than tv for me (and many others). eg. I can find papers on interesting topics that I would otherwise need to hunt down in libraries. And it's cold outside.
fyi, anyway. Maybe justifying the time you spend online would make you less cynical. Staying away from slashdot would help too.
re-read my post. Did I mention US shows anywhere? How did you infer that I think US shows rock? I didn't say anything about US shows. All I said was that almost all of those canadian shows mentioned suck.
We can apply a law...I forget the name: "90% of everything is crap." which applies equally to canadian and american television, and I can testify to this from experience, since canada has healthy doses from both sides of the border, whereas I don't think the US has much Can. programming.
"Consumers don't want open content - they want quality services at affordable prices. And that's what you'll get from eBabble Corp."
(from an interview with ebabble ceo responding to criticism after ipo)
Anyhow...
well, I wasn't being quite serious. The idea of trying to take usenet public is a bit off. The whole idea is that it's distributed and free, right?
So taking usenet is obviously not a possibility, but presenting web portals to usenet could essentially do the same thing (filtering content, etc), and then it'd be up to whoever had the most marketing bucks to convince all the new & clueless users out there that deja is just another web site with hundreds of thousands of users. Like you say, nobody would even know it (usenet) existed. I'd be irrelevant that the original content was open, cause the.coms would drown out anyone trying to make that known. It would be all about marketshare for a particular portal.
The portal could conceivably append a special sig to all posts from it's website altering copyright status...or at least licensing stuff, so they would (legally at least) have a bit more control.
Just take a look at how many usenet posts have the deja.com or remarq.com sigs. And that's just in the newsgroups I read (sorta techy comp.*), probably even worse in many other groups. How many of those people actually know about usenet...
Then look at a deja.com print ad. Not a single FUCKING MENTION of usenet or newsgroups. That's sleazy. The scenario above is a bit silly and pessimistic, but I wouldn't put it past them.
More generally, nntp seems like a special case for topical discussions, whereas http & html can do everything that usenet can, and more since it's a more general protocol and interface.
The big disadvantage, as someone pointed out, is that it's centralized. At least a particular forum is, like slashdot. I don't know how else it could work though, and there are advantages to that even.
Then it could go public (or at least get some VC; the biz folks love names like that), and could do some marketing.
Re:Why UseNet will remain popular
on
Is Usenet Dying?
·
· Score: 1
You don't have graphical access to the internet. Yes, text-based browsers make many things perfectly usable, but have you tried using board-type discussion forums using Lynx lately? Sites such as Slashdot are usable - but when you want to rapidly check on cross-references, determine posting status, etc, a newsreader such as 'tin' beats web browsing any day.
This is a good point. There is all sorts of info built right into the interface that a web forum just does't have. What does it need? Well, semantic markup would help. I wonder if xml could help make web forums (fora?) more useable in general, not to mention with simple textual interfaces. Of course, you'd need to make the browser clue into it, but the advantage would be a single client.
Re:For decades I have been annoyed with...
on
Lego Machine Gun
·
· Score: 1
I feel exactly the same way. They're called "legos" by the same people who pronounce "linux" with a long i.
MS windows buttons DO NOT have soft round edges to them. Look at any screenshot close up. You are imagining things. mswin has the most straight, hard, tight-assed bevels in the whole bloody industry.
re: highlights: AND WHAT THE FUCK IS THAT FAT BROWN OUTLINE ON THE GTK SCREENSHOT? It is *HIDEOUS*. I can see how you would like the gradient buttons, but I cannot believe you actually find that focus ring appealing. That's insane.
And what exactly does being a graphics programmer have to do with it? Did you mean "graphics designer"?
"Thank all the little gods! What a terrible way to do it. On the other hand, it does support dynamic theming and run-time loadable UIs. This gives you all of the advantages of editres and a whole lot more."
Actually, it doesn't. X resources (& the editres protocol) can be used to provide values for any property that an object decides to export, *including behavioral ones*. gtk exposes appearance to the "theme engine", nothing more.
Plus, editres lets you do stuff *dynamically*, which can actually be useful.
And loadable UIs is something different, built into neither Xt & associated widget sets OR gtk. There are libraries to dynamically load interfaces for both Xt and gtk.
The speed of Be is not in the threads, it in the "lets start from scratch and do this right".
Threads are no easier in Be than in any other operating system. And object-oriented programming (which you seem to equate with C++, which is a particularly crufty language for expressing OO ideas) does not make threads particularly easier.
perl does that (I don't know how good the implementation is though).
Anyway, what I was saying before is: a function is an abstraction. Implementations hiding behind interfaces as is the case with OO languages is another type of abstraction. The term "abstraction" is not something specific to perl, or OO languages, or computer science in general.
An example:
Interface Graphic { draw(... ); }
Circle implements Graphic { draw(... ); }
That's a Circle hiding behind a Graphic interface. What is actually happening (whether a circle or rectangle is being drawn) is irrelevant.
In C (and every other languages w/functions), we can do this:
count_active_users();
We don't care how this is actually implemented, as long as it gets done and gives us an answer. That's another abstraction. It's irrelevant that it doesn't get called through a pointer. If you called it through a pointer, that would just be another layer of abstraction.
Like you point out, implementing OO type abstractions (like implementation hiding behind interface) is a pain in the ass in C. Doesn't mean C doesn't have abstractions.
offtopic: Even cooler (imo) than simply hiding an implementation behind a pointer (ie. having a virtual function table) and calling the right method based on the actual type hiding behind the pointer, is dispatching based on not only the type behind the pointer, but the types (*real* types) of all the arguments: multiple dispatch.
I agree with you mostly, but that's a lame argument: every programming language that supports functions supports abstraction. The idea is not something that any particular languages can "support"; it's above that, and nothing to do with OO programming.
Butthead! There's lots of languages out there that are "safe" (no core dumps, like perl), have automatic memory management (no malloc, like perl), and that most importantly ARE NOT PERL.
If those are the only reasons you can think of to program in perl, then you are a truly lousy advocate.
(ps. that last paragraph was a brilliant piece of prose. I aspire to such heights of rhetoric.)
There are compilers that have direct support for this, but they are compilers for higher level languages, not C. Or C++. If you raise the abstraction level, you give the compiler more opportunity to optimize low level details. Telling the compiler how to optimize ("hinting") instead becomes giving the compiler more leeway in translation of your highlevel code to assembly language. You just have to make fewer assumptions about how your program will look once compiled.
Until we ditch C/C++, really intelligent compilers will not happen.
like he said, this is just notational. You could just as easily express the shorthand C = A + B (sum the values of two lists) as
C = sum_of_two_lists( A, B )
(in other words, with a function instead of a possibly ambiguous operator)
I agree with you, it (the operator syntax) is unclear. But that doesn't mean the concept is flawed. And the point was, if you have some mechanism to sum two lists (whether through an operator syntax or a function), that's better than rewriting a for loop every time you need it, and possibly introducing bugs. Plus, like someone else pointed out, there is more room for compiler optimization, since you know less about the internals of the operation, and the compiler has more "leeway".
Well, a better solution than just blindly adding more stuff to the server is to raise the abstraction level at the client end. Instead of making lots of calls to lots of APIs that invoke lots of special features of the server, make the client interface higher level, and do a better job of hiding the distinction between client and server. A good example is NeWS. You write snippets of postscript, and whatever is rendering it can do it's best to make it go as fast as it can. Or OpenGL with display lists. You're right about lots of calls to SetPixel being the wrong thing, but then do we end up with "DrawPolygonRotateShadeAndAddADropShadowThenDrawTh eButtonOnTop"?
I don't know TOO much about what I'm talking about, but making a clumsy distinction of the server then randomly adding features (which is really how it would be with X) seems like the wrong thing.
Plus with client side APIs, you don't really CARE where it's actually being rendered. If you have something nice and declarative (like a canvas type thing) the lib makes use of whatever it has, X server or what have you.
Slashdot Mirror
then fix the garbage collector instead of reimplementing random memory management mechanisms for every program you write.
wow. in that diagram, the asteriod matilde is even bigger than the sun, even. I'm worried. They say that it won't hit the earth, but that's a big piece of rock...
...and here is evidence to this fact you point out.
And I'm contributing to it!
Actually, the internet is more useful than tv for me (and many others). eg. I can find papers on interesting topics that I would otherwise need to hunt down in libraries. And it's cold outside.
fyi, anyway. Maybe justifying the time you spend online would make you less cynical. Staying away from slashdot would help too.
re-read my post. Did I mention US shows anywhere? How did you infer that I think US shows rock? I didn't say anything about US shows. All I said was that almost all of those canadian shows mentioned suck.
We can apply a law...I forget the name: "90% of everything is crap." which applies equally to canadian and american television, and I can testify to this from experience, since canada has healthy doses from both sides of the border, whereas I don't think the US has much Can. programming.
in the same way that iCraveTV has. Almost. Or should be, at least.
uh, as I am canadian, I must protest. All of those except Due South suck and if there are indeed canadian productions, nothing to be proud of...
Although Alan Alda (I think unless I'm imagining things) was on The Outer Limits once...but actually that was kind of depressing.
"Consumers don't want open content - they want quality services at affordable prices. And that's what you'll get from eBabble Corp."
(from an interview with ebabble ceo responding to criticism after ipo)
Anyhow...
well, I wasn't being quite serious. The idea of trying to take usenet public is a bit off. The whole idea is that it's distributed and free, right?
So taking usenet is obviously not a possibility, but presenting web portals to usenet could essentially do the same thing (filtering content, etc), and then it'd be up to whoever had the most marketing bucks to convince all the new & clueless users out there that deja is just another web site with hundreds of thousands of users. Like you say, nobody would even know it (usenet) existed. I'd be irrelevant that the original content was open, cause the
The portal could conceivably append a special sig to all posts from it's website altering copyright status...or at least licensing stuff, so they would (legally at least) have a bit more control.
Just take a look at how many usenet posts have the deja.com or remarq.com sigs. And that's just in the newsgroups I read (sorta techy comp.*), probably even worse in many other groups. How many of those people actually know about usenet...
Then look at a deja.com print ad. Not a single FUCKING MENTION of usenet or newsgroups. That's sleazy. The scenario above is a bit silly and pessimistic, but I wouldn't put it past them.
More generally, nntp seems like a special case for topical discussions, whereas http & html can do everything that usenet can, and more since it's a more general protocol and interface.
The big disadvantage, as someone pointed out, is that it's centralized. At least a particular forum is, like slashdot. I don't know how else it could work though, and there are advantages to that even.
how about "italk" or "ethreads" or "netbabble".
Then it could go public (or at least get some VC; the biz folks love names like that), and could do some marketing.
You don't have graphical access to the internet. Yes, text-based browsers make many things perfectly usable, but have you tried using board-type discussion forums using Lynx lately? Sites such as Slashdot are usable - but when you want to rapidly check on cross-references, determine posting status, etc, a newsreader such as 'tin' beats web browsing any day.
This is a good point. There is all sorts of info built right into the interface that a web forum just does't have. What does it need? Well, semantic markup would help. I wonder if xml could help make web forums (fora?) more useable in general, not to mention with simple textual interfaces. Of course, you'd need to make the browser clue into it, but the advantage would be a single client.
I feel exactly the same way. They're called "legos" by the same people who pronounce "linux" with a long i.
you are an idiot.
MS windows buttons DO NOT have soft round edges to them. Look at any screenshot close up. You are imagining things. mswin has the most straight, hard, tight-assed bevels in the whole bloody industry.
re: highlights: AND WHAT THE FUCK IS THAT FAT BROWN OUTLINE ON THE GTK SCREENSHOT? It is *HIDEOUS*. I can see how you would like the gradient buttons, but I cannot believe you actually find that focus ring appealing. That's insane.
And what exactly does being a graphics programmer have to do with it? Did you mean "graphics designer"?
"Thank all the little gods! What a terrible way to do it. On the other hand, it does support dynamic theming and run-time loadable UIs. This gives you all of the advantages of editres and a whole lot more."
Actually, it doesn't. X resources (& the editres protocol) can be used to provide values for any property that an object decides to export, *including behavioral ones*. gtk exposes appearance to the "theme engine", nothing more.
Plus, editres lets you do stuff *dynamically*, which can actually be useful.
And loadable UIs is something different, built into neither Xt & associated widget sets OR gtk. There are libraries to dynamically load interfaces for both Xt and gtk.
The speed of Be is not in the threads, it in the "lets start from scratch and do this right".
Threads are no easier in Be than in any other operating system. And object-oriented programming (which you seem to equate with C++, which is a particularly crufty language for expressing OO ideas) does not make threads particularly easier.
perl does that (I don't know how good the implementation is though).
Anyway, what I was saying before is: a function is an abstraction. Implementations hiding behind interfaces as is the case with OO languages is another type of abstraction. The term "abstraction" is not something specific to perl, or OO languages, or computer science in general.
An example:
Interface Graphic
{
draw(
}
Circle implements Graphic
{
draw(
}
That's a Circle hiding behind a Graphic interface. What is actually happening (whether a circle or rectangle is being drawn) is irrelevant.
In C (and every other languages w/functions), we can do this:
count_active_users();
We don't care how this is actually implemented, as long as it gets done and gives us an answer. That's another abstraction. It's irrelevant that it doesn't get called through a pointer. If you called it through a pointer, that would just be another layer of abstraction.
Like you point out, implementing OO type abstractions (like implementation hiding behind interface) is a pain in the ass in C. Doesn't mean C doesn't have abstractions.
offtopic:
Even cooler (imo) than simply hiding an implementation behind a pointer (ie. having a virtual function table) and calling the right method based on the actual type hiding behind the pointer, is dispatching based on not only the type behind the pointer, but the types (*real* types) of all the arguments: multiple dispatch.
Code Complete or Writing Solid Code?
Or rather, which would you recommend?
I agree with you mostly, but that's a lame argument: every programming language that supports functions supports abstraction. The idea is not something that any particular languages can "support"; it's above that, and nothing to do with OO programming.
Butthead! There's lots of languages out there that are "safe" (no core dumps, like perl), have automatic memory management (no malloc, like perl), and that most importantly ARE NOT PERL.
If those are the only reasons you can think of to program in perl, then you are a truly lousy advocate.
(ps. that last paragraph was a brilliant piece of prose. I aspire to such heights of rhetoric.)
I think you mean: "the more abstract a language, the *more* win from compilation".
Right?
There are compilers that have direct support for this, but they are compilers for higher level languages, not C. Or C++. If you raise the abstraction level, you give the compiler more opportunity to optimize low level details. Telling the compiler how to optimize ("hinting") instead becomes giving the compiler more leeway in translation of your highlevel code to assembly language. You just have to make fewer assumptions about how your program will look once compiled.
Until we ditch C/C++, really intelligent compilers will not happen.
like he said, this is just notational. You could just as easily express the shorthand C = A + B (sum the values of two lists) as
C = sum_of_two_lists( A, B )
(in other words, with a function instead of a possibly ambiguous operator)
I agree with you, it (the operator syntax) is unclear. But that doesn't mean the concept is flawed. And the point was, if you have some mechanism to sum two lists (whether through an operator syntax or a function), that's better than rewriting a for loop every time you need it, and possibly introducing bugs. Plus, like someone else pointed out, there is more room for compiler optimization, since you know less about the internals of the operation, and the compiler has more "leeway".
Peter
Well, a better solution than just blindly adding more stuff to the server is to raise the abstraction level at the client end. Instead of making lots of calls to lots of APIs that invoke lots of special features of the server, make the client interface higher level, and do a better job of hiding the distinction between client and server. A good example is NeWS. You write snippets of postscript, and whatever is rendering it can do it's best to make it go as fast as it can. Or OpenGL with display lists. You're right about lots of calls to SetPixel being the wrong thing, but then do we end up with "DrawPolygonRotateShadeAndAddADropShadowThenDrawT
I don't know TOO much about what I'm talking about, but making a clumsy distinction of the server then randomly adding features (which is really how it would be with X) seems like the wrong thing.
Plus with client side APIs, you don't really CARE where it's actually being rendered. If you have something nice and declarative (like a canvas type thing) the lib makes use of whatever it has, X server or what have you.
repeating myself trying to make my point...