These really are interesting from a few points of view if you stop and think about it before immediately criticizing it at face value.
First, from a person who loves video games and enjoys adventures with involved stories and not-very-exceptional graphics (take Final Fantasy 6 or many snes games), it's interesting from an almost nostalgic point of view. I don't know how to explain it exactly, other than to say that it's the sense being aware of more happening than is literally presented visually. Take the coin flip in FF6... simple, low-detail, low-framecount graphics, but the awareness of something emotionally moving taking place.
From another point of view, seemingly an opposing one (I haven't quite decided yet), you have something to show the violence-in-video-games people, I suppose.
I think they're pretty interesting. I guess it appeals to me more as a gamer, though it's not something I'd hang on my wall, it's still intriguing.
Yeah. Now imagine all the cool things we could do if we could harness the dreaming capacity of our minds consciously. Who needs VR.:) Dreaming could be a whole new form of entertainment, then we just figure out how to do multiuser dreams, and we're really into the realm of science fiction.
I wonder if there's been research done on this. I'd be suprised if there hasn't; I just haven't looked.;)
Remember, tetris is about realtime calculation, not about problem solving. I don't think this is suprising at all, really, because I don't see how dreaming about tetris can give you practice at it (since there is no set problem to solve) unless your dreams are really accurate;), or speed up your thinking at the time you actually play it (see practice).
I don't think this experiment was well-chosen. It'd be more interesting with some more non-realtime strategic game, or something similar with set problem forms.
Then again, I've been rather interested in sleeping and dreaming and have observed some interesting things, such as the sleep transition period, and some dreams themselves. I've found that there isn't a point where you "fall asleep," it's much more of a stretch of time and change of consciousness where your thoughts about doing something become you actually doing it. It's like being able to remember intellectually the taste of chocolate, but a wall of consciousness slowly disappears and you really can taste it.
As you said, though, this isn't usually something you tend to remember.
Your reasoning is incomplete. I believe this legislation is
ridiculous and the reasons you mention are directly related to this. (NOTE: This is a response to student's notes, not direct copies of lectures. The latter, I agree, should be a copyright violation, without express consent from the author.)
First, you state "I created the lecture." This is true, but what
exactly is a lecture? It's your filtering of ideas (very likely not
your own) into a format that can be presented in a short period of
time. This can include your own thoughts and insights, but likely the
vast majority of information is merely filtered information. (If you
by some chance are the third- or forth-sigma professor who is
presenting mostly original information, perhaps this does not apply,
but I think broad legislation for Given this, you must now present your lecture to students who have
paid the university (thus paying you), and who now must do a good deal
of mental work for themselves to filter and process the information
you've presented in order to understand it. After having paid you for
your efforts, why should they be restricted in their efforts?
Let's extend the reasoning here, first backwards. If they are not
allowed to profit off the information they've paid you for that you've
gathered and processed, why should you be allowed to profit off
information the authors of the books and materials you gathered your
information from? Likely you didn't pay every author you have on your
class bibiography. (You do have a biliography and at least give
credit, right?) Libraries, for instance, and the web are wonderful
resources. However, as you state, you don't want people making
derivative works of your work and profiting from them!
Now let's continue to extend this in the other direction. Now that
students have learned from you, after having paid you and done the
work to learn, perhaps they shouldn't be able to profit at all!
After taking your lecture, they should never be able to work and make
money from the concepts they might have learned from your class.
This is of course, ridiculous. The reason we go to a university is
to learn so that we, too, can extend our knowledge and someday be able
to use it to support ourselves.
The real motive here is monopolization of the flow of information.
Students could learn instead by going directly to your sources, but
that would be more effort, perhaps an unreasonable effort, so they
come to you, and you profit from this, because they are willing to
pay. However, some students may be willing to pay for further help
and further insight, yet you wish to limit this, because you wish to
beh te only source of this information. I find that a rather
appalling position for university faculty.
If we wish to completely limit the profitability of information,
retain complete control on its flow and on the flow of profit from it,
then information will never be able to be used. We are an
information-based civilization. The implications are frightening.
Instead of condemning the article which others have done here quite
thoroughly, for the better, I'd like to step aside a second and wonder
about the potentially good side effects of this report:
Legal validation of Free Software/Open Source licenses. If the
government is looking to encourage open source software, could this
lead to the long-sought-after validation of our prized licenses, since
they'll want to make sure whatever licenses they're under stand up in
court?
Open specification "encouragement". If they want a level playing
field for Open vs. Closed software when making their considerations,
could this give a push towards making sure specs for certain things
(say, like various pieces of hardware and protocols, and even maybe
DeCSS?) are available for use in Open Source software? (Somehow I
doubt it, but wouldn't it be cool?:P;)) At least if they
want their software to interact, they'll need to make sure the OSS
can communicate with the non-OSS...
Then again, this is probably just asking for more laws to be
made, which may not be so good, either.
I'm not a lawyer, or very familiar with how these things might work,
so is there anyone who is that might comment?
(This may be moderated down as a troll, or as being flamebait, or
whatever, but it should be said. Does it make you uncomfortable?
Does it tweak some part of you that says maybe you shouldn't be doing
these things? Maybe it should.)
Who cares about ideals! Who cares about individual freedoms and
rights! As long as I'm comfortable and entertained, people should
just stop whining! Conform! It doesn't matter, after all; besides,
relax, sit back, watch a movie, pop some soma, don't worry, and be
happy!.
...right. Our rights are being whittled away here. It's not going
to stop; it's not even just started: we're in the middle of it. And
it's not going to end until we're all restricted by law into being
nothing but mass consumers.
The hypocrisy we see here is pretty sad, too. On one hand, it's
down with the MPAA, down with Microsoft, down with RIAA, and down
those things that take away our freedoms. On the other hand, we see
CmdrTaco and other slashdot authors buy DVD's (supporting the MPAA),
buy and use Windows (supporting Microsoft), buy CD's (supporting the
RIAA), and generally don't take action on their loudly-stated beliefs.
If you believe these things, if you truly support your
viewpoints, give up these comforts and frivolities.
Don't buy DVD's. But your favorite movie came out! Tough.
If you believe that the MPAA is wrong, don't buy it. You'll live.
Don't buy/use Windows. But this cool new game just came out and
you have to have it! Tough. No you don't. There are plenty of other
games out there. (This of course only applies if you have something
against Microsoft, their business practices, whatever.)
Don't buy CD's. But this great new album I've been waiting for
just came out! Tough. You don't need it. Go buy non-RIAA labels
instead (if you can find some, and there are plenty). Go make music
yourself and distribute it. Whatever.
You know what? It's perfectly possible. You can find things to do
with your time, entertainment or otherwise, instead of wasting it on
supporting the things you say you don't support. Try it.
(By the way, DVD's really aren't that much
better than VHS. Sure they're more portable, and hold some more data,
and you can make exact copies, but average video quality is only
slightly better. In many cases, it's even worse.)
And I want you to remember, every time you buy a DVD, you just
gave money to the MPAA to support their case. You did. And you
told the world that, no matter what you vocalize, you don't really
care about your rights. Consider it.
No sub-selects (these "might be" available in 3.24)
No SELECT INTO.
No transactions. (Unstable development software does not
count. If you have someone who wants to commit their data to an
unstable version of a database, get a new DBA.)
Stored procedures and triggers. ("We want to add this in the
future")
Foreign Keys (there are given "reasons NOT to use FK's" which
scare me considerably if the developers of a database actually believe
this!)
Views (again, "in the future")
"--" for comments (because they happen not to like this! Well,
screw the standard, who needs one, right?)
MySQL has no referential integrity. (Under some definitions, this
excludes it from even being considered a RDBMS.) It certainly lacks
PostgreSQL's object-oriented capabilities, which are highly
useful, such as table inheritence.
PostgreSQL has all of the above features, and has had them for some
time (with the exception of FK's, which are new to 7.0). It is
stable and well-tested. MySQL developers are still working on these
features. I'd say MySQL has quite a way to go before it reaches
PgSQL's "last line of defense".
I didn't mean a natural language for programming, but it might make a "cute" user frontend. As you said, and as I suggested, and "integrated" CLI/GUI. Maybe you don't like that either, I thought it might be kinda neat though, even a "constrained" natural language syntax, especially for new users. Either way, some form of input to do selection and various other things we all know are faster from the command line.;)
I won't get into a big language discussion here (re: Python). I don't really care for Python, mostly because I find it simply doesn't do anything well enough that something else doesn't do better, or at least as well (not to mention the current implementation has some performance issues). I could go on all day about various features of various languages though. However I'd like to show a little something "cool" about a pure object-oriented system.
First, by a pure system I mean it includes (but is not limited to;) the following:
Everything is an object, of course, and objects and classes are "first class," that is, they can be made and manipulated at will, by the user. (The usual definition is "at runtime," but by nature of the system, everything is "at runtime" anyway.)
The system is "unified," that is, the classes that are created as a developer are the classes used directly by the user. The developer does the equivalent of, in C++-speak, class Image : public DocumentObject {... , and the user directly instantiates this class (new Image). (Not that the user touches or sees code, but it is quite literally the same thing.)
Base classes are part of the system as well, such as Integer, String, Real, etc.
As an addendum to point 3, there is a CodeBlock object, with appropriate methods for running, including standard constructs such as for, while, if, etc.
This is the "little something": by virtue of unification (point 2), the objects from points 3 and 4 are available to users directly. Now say we have a particular subclass of CodeBlock that is a mere list of method calls, with parameters, to other objects in our system. What we have is a complete "language that isn't a language"! Let me be more specific; we have all the elements of an object-oriented programming language here, but no actual syntax itself. For instance, given "code" such as the following (in whatever horrible crossbreed language this is *grin*):
if(Date::getToday() > "12/13/00") { new StickyNote n; n.text = "Your flight leaves tomorrow morning at 6, get packed!";
relate n "on" Desktop; rename n "Plane trip tomorrow!"; }
or something equally inane (OK so it's after midnight and I can't think of a good example, sue me;), we can break all this down into nothing but method calls and objects (and a few calls to the object system, which amounts to something similar). For instance, the block between the braces will be a CodeBlock, which has the if(Boolean) method being called on it, which is being passed a parameter that results from the operator> being called on the result of Date::getToday() with the string parameter... well, you get the picture. It's fairly easy to break this all down.
There are some rather neat implications here, and if I just know they're going to scare everyone away because "that's been tried and doesn't work." However unless you've been asleep (as well you might, you might find this dry reading), you probably see them already. One is that all you need is a parser for a given syntax to "translate" into this set of method calls, and you've got (in theory, always in theory;) "portable," "compiled" code. Since even if you write this in C, you're merely going to be making many of these calls to your object system anyway, for many things performance won't be any different. (Of course, with anything that does tight loops or number crunching, making object system calls for each Integer and Real will likely be a drag. That's why we still can write CodeBlock objects in C, C++, or anything else.;) Perfectly acceptable for your scripting language, though. And everyone gets their favorite syntax.
The other thing you might find equally horrible is this can be done totally "visually." Just drag a whole bunch of methods and objects together, use arrows to show which goes where, and presto. Same output, no "code". Nice for newbies and such, maybe even to debug visually ("decompiling" these "scripts" is trivial of course), maybe even nice for building the equivalent of those long command-line pipes. Who knows. It'd be pretty cool, for instance, to have a couple separate "boxes" that gather data independently, and then put the results together... easy parallelization here...;)
Anyway, for those who haven't fled in terror or marked me as mentally disturbed... oh, so no one's left.;) Well, I hope you at least get a glimmer of the real flexibility that's brought about by such a system. The possibility of a "language that's not a language" isn't meant to turn users into programmers---something not likely to happen---but rather demonstrate another aspect of the inherent beauty and elegance that such a system brings about naturally, by the very nature of its design.
But how do I distinguish between a text editor and a word processor? How do I distinguish between typing text into the text widget of the gimp and typing text into my text editor and typing it into my word processor?
This immediately assumes an application model already. I know it is quite difficult for you to do otherwise; it is for everyone I talk to, until they switch their thinking around.
Of course, that doesn't answer your question. And before I start, I'd like to say that there were a lot of things I left out in the original. I'll try to cover some more detail and depth this time around. And now for the answer: why would you regularly be opening your word processor or text editor?
To write a document or edit code (likely), of course. In an OO system, you might take a Page object and make a FormattedText frame in it (or likely you'd have a template of this). Or then again, you might just start typing text, and the system would bring up a "text buffer" of sorts you could type in. You could later take this bit of text and put it where you wanted (format it, whatever). That's another way of doing things. There are many possibilities: the important thing, the extremely important thing that you see here, is that you're not just running a program. It may seem similar to you, but the difference is incredibly important. How is it different?
Let's take the first model. You have a Page object. This object has properties such as size, and all it does is contain subclasses of DocumentObject. Each DocumentObject has properties such as size and dpi, and methods such as render(). A Document is nothing more than an ordered set of Pages. There is nothing saying a Document must be text; it might be a drawing, or a musical score, or a combination of the above. Each different thing, such as a MusicStave or Image is just a subclass of DocumentObject, and thus Page wouldn't care. "But, but," I hear you exclaim, "how is this different from OLE or other embedding?"
It is both subtly and enormously different. Subtle because you have similar ends: one sort of medium in another. Enormously because almost everything else is different. There are no applications here; you're not embedding Word in Excel in Explorer in Word in MyPhotoEditor2000. Ask yourself: once you start embedding one application in another, and one changes into the other, why are you bothering with applications at all? Why do they need to be there at all? Of course, they don't. Programmers don't have to go to painful lengths and write horrible hacks to make their programs interact with each other via OLE or CORBA or COM or whatever the latest fad is; they simply write objects, with the simple functionality they contain, and by the nature of the system these objects work together.
Next:
The only way that I can see, short of omniscient computers, is to do something which is the equivalent of launching a program. Calling it changing modes, shifting paradigms, praying to the archangel gabriel. I don't care, but someone, unless this computer is psychic, I have to tell it what I want.
I hope I have in some small way shown why this is not equivalent to launching a program. Telling the computer what you want does not imply programs and applications. Having the computer respond to what you're doing automatically does not imply you won't have to ever tell it what you want. But the difference is extremely important. Oversimplifying is shortsighted, and will continue to lead down the wrong development path until it is corrected.
At that point, you're right back to./dns2reverse.pl and frankly I don't really believe that you're going to come up with a much faster interface than the command line.
I'm not sure what dns2reverse.pl is, but I have not said or implied that textual input is in any way dead, obsolete, unnecessary, outmoded, outdated, or even less important. The opposite is true. With a proper object-relational system, you can bring textual commands to a new height. A "natural language" like frontend beside a GUI might even be the best and most useful thing for both experienced users and new users alike. What you say next relates to this:
So if we take a step back from input and just focus on file storage, doesn't everyone realize that a filesystem is nothing more than a relational object database?
I don't know if you're oversimplifying or you just don't know what a general relational system is, but a filesystem is merely a very limited form of the relation, that is, containership. The world is not hierarchical. With a true relational system, you could specify that an object is "next to", "over", "under", "inside", "part of", or any other number of relations. Hierarchy is easy to do with this... objects are merely related to containers as being "in" them. However, a more general relation is quite a bit more useful. A document might be "part of" a project, and also "in" something else, perhaps "related" to a different document. A conventional filesystem is not optimized for handling general relations like that.
Back to the textual input interface, though. Once we have established a relational layout, we can easily say things like "show me everything related to Project XYZ." Or, "show me all Graphic objects in reports from last year over 1 megabyte" and get a "query window" that would be similar to your typical icon view of a directory today. All the data is now there and accessible. The possbilities are endless, and the flexibility...
And UNIX even has the object-stream method, more or less (more less than more, in practice). Make every data file you have executable...
You don't understand what an object is. Go get a good book (there are any number of good books on the subject), and read what encapsulation, polymorphism, inheritance, and abstraction are. They aren't fancy buzzwords; they define what it means to be object-oriented. To back this up, your example lacks encapsulation (the data and functionality aren't bound), inheritance (doesn't even make sense here without encapsulation), polymorphism (no methods or inheritance and nothing to be polymorphic), and abstraction (no context - the data itself is meaningless bits and bytes).
I've got a friend who rants about the everything-is-an-object model once every month or two. The problem with it is that it isn't how life works.
I've looked around, and I can't find anything in "life" that isn't an object. If you can find something that isn't an object (it can't have any properties, for instance), then I'd like to hear about it. Of course, "nothing" might not be an object, but then, if nothing isn't an object, then everything is an object.;)
But please don't ever make a system which requires you to describe the data that you want by the data that you want rather than some external artificial description. I'd much, much rather use logo7.jpg than "The logo in the burgendy shade of red which is bump-mapped a little more than logo6.jpg and I airbrushed..."
There's nothing requiring you describe anything. However "logo7.jpg" is hardly descriptive of anything, I'd sure not want you to organize my graphics collection. However, you'd likely want a "title" property (short) and perhaps a "description" or "comment" property where you could expound a little more on the thing, so you could make searching easier...
Oh, and computers do make a difference between code and data.
I did not say that there was no difference. I don't know how you got the impression that I did. (Or is this a straw man? I said they don't force you into a program model; rather they execute code which manipulates data.)
If it was that revolutionary it would have revolutionized by now.
I take it you believe every concept possible has been considered and either implemented or shown useless, and that nothing new and exciting can be done. What a dull world!
New things can be done. New things might even be getting done. We just have to avoid this geezerly "it's been done this way since my gradpa's grandpa and aw say there ain't no other way to do it!" attitude, step way back, and evaluate whether there isn't a more useful way of doing things. For some things, the old way might be the best. For this, programs and applications must be replaced.
This article may purposefully be controversial or not, likely it is. Things that make people think and re-examine current ideas usually are quite controversial.
However, your proposition that a computer is a "device that runs programs" is incorrect, perhaps subtely, but the mistake is very important and the reason the rest of your reasoning is also incorrect. Let's look at this a bit more closely.
First, your statement. At the core, a computer does not run "programs". It executes code, which in turn manipulates data in some fashion (whether moving it to the screen or to a disk, it's data). What's the difference, you ask?
Saying that a computer runs programs presupposes an organizational model, a split between data and functionality. However, a computer doesn't presuppose this at all, as we can see if we examine it at a lower level. "Modern" operating systems, of course, make this supposition, and their underlying model is what "forces" higher levels of activity (developers and users) to also operate under this supposition. In fact, we've been using operating systems that function in this manner for so long that for the most part we all merely assume that the computer itself imposes this model on us. This isn't so! Why is this important?
When someone suggests another model, our assumption that the computer forces us to our current model blinds us to the possibilities, and even the very nature, of the newly-suggested system. As developers we no longer even take the time to consider a better way of doing things. If something needs done, we write as program, because it's programs that get things done! Or so we're lead to believe. So we continue to believe, as we wander further and further down an increasingly difficult path of programs, applications, and files. What's wrong with this path, though?
After all, we've been using programs to do things for us for the most part sice the first computer was built. Old doesn't imply that this is bad, so what's the problem? Computers are a tool. They are meant to be used to aid in whatever we're trying to accomplish, like any other tool, whether this is to write a book, or simply relax to a nice game of Quake 3. Just like any other tool, though, the closer they fit the problem, the better off they are. You want a hammer for a nail, after all. Programs, however, come in two varieties: applications, and utilities. Applications simply don't scale. They grow into larger and larger monstrosities of code, adding whatever new "feature of the week" seems cool to the developer or marketing department, and only interact through kludgery and hacks (such as OLE and related mechanisms). Applications aim "shotgun-style" to hit a broad segment of functionality, and if it doesn't do what you want, you're out of luck. Unix-style utilities on the other hand do a single thing very well, and are typically built to be useful in a chain of interaction (such as a pipe or other redirection). These have problems to, but different ones. Typically they require knowledge of how to get from what you've got to where you're going, that is, which commands will get your data, modify it in the way that you wish, and then output it to where you want. Often they require "data frobbing" along the way to make the next utility understand what the last one said, since the stream of data has no meaning outside what each utility gives it. So what would be better?
An object-oriented (OO) system, as many people have suggested, is really the next step (no pun intended) above a utility-centric system. As I'm sure you know, an OO model reorganizes ("encapsulates") code and data into units ("objects") that, because of the encapsulation, have the implicit meaning which our streams lacked. (They also add a lot of other things I won't go into, because I'm sure you know, and it's not necessary here.) This is not fundamentally different from how a computer works. It is merely a more useful reorganization of what a computer already does, namely, executing code (object methods) and manipulating data (object properties). How is this more useful?
Objects can interact without the problems encountered with utilities, but retain all the advantages. There is no need to worry about how data is formatted so that something else may parse it, but rather each property can be queried directly upon request, when necessary, if necessary. Objects remain independent, focused only on what they do, without growing features out of control to handle every case under the sun. We can use these objects as building blocks to form what we're after: they model every situation we can come across with a great degree of accuracy. How can I make such a broad statement? Look around where you're sitting right now. Your desk, you monitor, keyboard, pens, paper, books, etc. They're all objects. Everything we use and work with is an object already: it's natural. This is another major advantage (and also for some, a disadvantage): we're used to objects. People already know how to work with them. Unfortunately (and here's the disadvantage), we've all been conditioned to working with programs so long, that using objects on the computer seems unnatural. We can't think of any other way of doing things than opening up an application and saving that file. Here's the test though: what happens when you sit someone down who has never used a computer before?
Usually, they want to start typing, or start drawing, or immediately attack their problem at hand. Instead, they have to go through a set of unnatural and unusual steps, like starting up the word processor or drawing program, making a new file (of what type?), and any other number of things, before they can start writing or drawing. And once they've done that, they're not done! They have to save it, which is quite a foreign concept to most (after writing on that piece of paper, do you have to tell it to remember what you just did? I don't think so.) So, how would these common actions work in a totally object-oriented environment?
Instead of starting a program, and making a new document, you might simply grab a piece of paper, and start typing onto it. Or, pick up your tablet (or grab your mouse), and start drawing onto it. The code to decide what tools to present is trivial - if you don't believe me, look at GIMP or any other device-context-aware program. Pick up a tablet stylus and it'll switch properly to the last tool you were using. Same with the mouse, etc. Once you're done? You're done. You wrote that chapter or drew that picture, just put it away. Objects are persistant, and this is natural. But how to restore that change you didn't want to make? Or revert? Undo, and version control. Already been proven to work. But how would "other" things, like Quake, work, in such an environment?
Same way. Each quake level is still composed of objects that do things, have certain methods. Quake levels themselves are "containers" for these objects. Internal representation is up to the implementation of the object. Fast 3D display is for an interface object (a "View") which determines how to display these. (A level editor would be much the same, use the same objects, but present a different view.) Simple, see?
This is important. Hopefully this will cause those of you who chance to read this to stop for a moment and think of the possibilities, and a better way of doing things, and maybe someday we'll even see a system like this.
OK, this one was just too hard to resist. I wonder what ERB would think. If NASA's making atmosphere plants, I wonder how long it'll be before we can ressurect Helium and pick a new Jeddak...
See, this movie would have been fine if it had done one thing: not purported itself to be real. Mission to Mars implied that "this is how it really is, no really", when in fact it's obviously a bunch of pseudoscience crap.
Star Wars, on the other hand, is fantasy, fairy tale... not science fiction. It says "what if the world were like this," and "just imagine." This affords a lot more suspension of disbelief.
Remember, in science fiction, the science is supposed to be "right," but everything else is made up.;)
Yes this looks very interesting, I'll check it out and maybe switch over. Looks like it has a package-management-style interface (epkg) and package "format" without losing the ability to stow any old thing. Very cool!
Any OS that doesn't have symbolic links can... uh, never mind.;) Are there any unices that don't...? I'm afraid I've only worked with Digital, AIX, Solaris, BSD, and Linux... any widely-used filesystems out there that don't, or any good reason for avoiding them...?
I think supporting non-unices is rather a nonissue, since they tend to be so different that you couldn't have such a scheme generic enough to satisfy them all. Perhaps, though, you could have a system that says "this is a binary, this is a config file", etc., and the backend would install it in the right place. (Like automake, I guess.) For unices with symlinks you'd use a scheme like stow, and for other OS's you'd use something they like.
Actually I really do mean/lib. I did it once, too.:) I wasn't using stow per se, but a little script I had hacked up (before knowing about stow) to do the same thing.
Even if all your stuff is dynamically linked you'll be OK unless you blow away the package directory with libc. (But by that point, you're really screwed, anyway.) For one, your shell probably has built-ins that do things like mkdir, and even if they don't, don't forget about LD_PRELOAD magic.
Just don't have root running a dynamically-linked shell, or don't log out.;)
Actually all you have to do is make sure stuff is in a properly laid-out format and stow will happily do its magic. (It'll do its magic regardless, you might just have a mess on your hands if it's not proper though.;)
I could say that naive users shouldn't be administering systems. Maybe I'd even be right in certain contexts. But realistically, new (Linux) users aren't going to be able to compile stuff. (They aren't. When people who can ask questions like "This says, 'error: unable to find freetype, please install it', what does it mean?", you know the total newbies are going to be lost.) Encap as mentioned below (or above I guess depending on your comment ordering;) might be able to solve this, and allow regular package management without relying on or requiring proprietary formats.
Ports have always sounded pretty cool. But from what I've seen, it's not the complete solution we're talking about (where you put the files, and how you remember what belongs to what, etc.), but then, I haven't really used them, so I'm probably wrong.
(For clarification, I'm a RedHat user at the moment. I've used everything, from building my own system from the ground up, to Slackware, Debian, and even other lesser-used distributions such as Yggdrasil...;) Package formats such as deb and rpm are proprietary, not in storage format (rpm's use cpio or something), but by composition and requirement. They are composed in a format that is exclusive to their own system of doing things (having specific files in the archive with meta-data about the package). They require their databases and their tools for using. They also require someone specifically construct them. (Waiting for that latest release of XFree86 or some other shiny new thing? Both Debian and RH have at one time or another lagged behind.)
This isn't necessarily bad, it's just rather limiting, and at times frustrating (try extracting a deb or rpm without the proper tools... rpm2cpio, whatever deb has...), but it works. The thing here is that something more generic can be used in the same way.
You're right though. Requiring everyone know how to build from source is going to restrict Linux. But perhaps we can come up with a solution using stow-like methods and a more newbie-friendly frontend (encap maybe?).
Actually stow offers the same advantages as before. You just stick stuff in its own directory, and stow it. If it's not in bin,lib,man etc. format, you can put it that way with little trouble. (For totally problematic packages like StarOffice which just make a big mess, I have a separate/usr/local/packages directory where things go and don't get out-linked. Easy enough to make a menu entry to launch the given application, and keeps things clean.)
Dependencies tend to be a non-issue with autoconf. If you're missing something, it'll tell you what to get and where to get it. Some sort of automation would be nice here, of course. It's certainly possible (look at Perl's CPAN shell), and would make building pretty easy.
It does handle conflicts, though, by telling you there's a conflict. I don't know how else you'd want this handled, but I'm sure any number of schemes could be devised.
Hmm yeah, I think deb's and rpm's both can build from source too. Encap (as mentioned by another poster below) seems to have some of the above mentioned features though. Probably using one of the post-install scripts one could go about running a configuration thing too, but I'd much rather prefer a linuxconf module or something similar.
What needs done is much simpler. Currently popular packaging systems need dumped in favor of GNU Stow. Then we don't need to change automake and autoconf at all, because they work as-is.
Dependencies could be added to Stow by someone without a lot of trouble.
For those who don't want to download and install it to figure out what it does (althoug you should! It makes life very easy if you do any source installs), GNU Stow takes "packages" that have been installed in the standard manner (things placed properly in bin, lib, man, etc.) in their own directories (such as/usr/local/stow/) and makes links to the parent directory's bin, lib, etc. You can tell by a simple ls -l what a file belongs to. Since the links in the directories aren't the "real" files, you can delete and restore them with minimal trouble (I challenge someone with a conventional system to rm -rf/lib and restore it, without rebooting). You can even maintain multiple simultaneous versions of packages. Autoconf already makes this easy to use, simply supply the --prefix= parameter to your configure scripts.
No silly proprietary formats, nor waiting for someone to come out with the latest package in your favorite format, no trying to convert foreign packages to your system. Everything you can find in a tarball is now pre-packaged and waiting for you to install...
Here we have a dilemma, or so it seems. On one side, we have "Linux deserves better marketing". We as Linux users (for those of us that are, and I'm sure there are those reading this who are not) see this and say "yes, it does... I want to use Linux everywhere I work, because (I enjoy it|it makes my life easier|it's fun|it looks pretty|whatever)".
On the other side, we see "It is the acronyms and not the technology that is of prime importance when selling to the corporate server sector." After all, that is what seems to sell and promote OS XYZ over Linux/unix. Then the hackish nature in us reviles, and we imagine ourselves not working on those things that are of importance, those things that are useful, those things that we should do because they are what need doing, and instead work on glitz, paperclips, and TLA's.
And we are right. On both counts. This is not a dilemma, we do not have to "sell our souls" to the corporate nature as this comment would seem to imply. Do we not understand "a new paradigm"? How is it that we have created a new market, a Free and Open Source market, one totally unheard of, yet one totally successful?
Who is it who is unwilling to change? "and nothing you can say will change my mind" Who flames, who insults; who is set in their ways, who unwilling to create a new market where technology does matter, not TLA's and buzzwords?
I suggest we learn. Not to compromise our ideologies in order to conform to a market, not in order to have higher sales and make more money. I suggest we learn what is best, to write software that doesn't mimic poorly, but does its job the way it should. To come up with a better way to market, but not necessarily the old way, not to compromise what has been worked so hard for to escape.
Our marketing and promotion is working. There is a slow, sure change on a level which others cannot compete by covering bugs with glitz. If this can be improved, if it should be improved, we need to come up with a truly new method that doesn't treat those who simply are not trained in our field as dogs, to be "thrown a few buzzword bones to chew on". How dare we insult people who have merely different interests, and have different knowledge circles and goals than we? They trust the journals and articles they read because they do not have any knowledge in which to judge.
Show the difference! Explain the importance! They don't have interest in knowing the difference at a code level, nor need to. But we have something different, something better, we can and should show it as such. Why change what Linux is to match what NT is? What point then is there to move from NT?
And those who are unwilling to change will, unfortunately for them and for us, be left behind. But it is their choice.
Right now it is... but the fact DVD-RAM's are only... let's emphasize ONLY... $500 or so, probably indicates this won't be cost ineffective for long.
Remember how expensive CDR's used to be? Look how cheap they are now, and how much they've dropped in price.
Now, if the same percentage reduction came about for DVD-RAM's, it'd be cheaper to burn DVD's than CD's. (Do you "burn" DVD's? If they're not ROM's, it must not be permanent... whatever.;)
And for the most part I didn't mean this for a "home grown piracy job," just people who know they're getting this sort of "self-destructing" media will merely make a copy the first time and throw out the one they bought.
Interesting legal issue there, too... are they agreeing to only own a working copy for X number of days? Or is making a permanent copy legal? Hmm.... IANAL, so I can't comment.;)
Slashdot Mirror
These really are interesting from a few points of view if you stop and think about it before immediately criticizing it at face value.
First, from a person who loves video games and enjoys adventures with involved stories and not-very-exceptional graphics (take Final Fantasy 6 or many snes games), it's interesting from an almost nostalgic point of view. I don't know how to explain it exactly, other than to say that it's the sense being aware of more happening than is literally presented visually. Take the coin flip in FF6... simple, low-detail, low-framecount graphics, but the awareness of something emotionally moving taking place.
From another point of view, seemingly an opposing one (I haven't quite decided yet), you have something to show the violence-in-video-games people, I suppose.
I think they're pretty interesting. I guess it appeals to me more as a gamer, though it's not something I'd hang on my wall, it's still intriguing.
Yeah. Now imagine all the cool things we could do if we could harness the dreaming capacity of our minds consciously. Who needs VR. :) Dreaming could be a whole new form of entertainment, then we just figure out how to do multiuser dreams, and we're really into the realm of science fiction.
I wonder if there's been research done on this. I'd be suprised if there hasn't; I just haven't looked. ;)
Remember, tetris is about realtime calculation, not about problem solving. I don't think this is suprising at all, really, because I don't see how dreaming about tetris can give you practice at it (since there is no set problem to solve) unless your dreams are really accurate ;), or speed up your thinking at the time you actually play it (see practice).
I don't think this experiment was well-chosen. It'd be more interesting with some more non-realtime strategic game, or something similar with set problem forms.
Then again, I've been rather interested in sleeping and dreaming and have observed some interesting things, such as the sleep transition period, and some dreams themselves. I've found that there isn't a point where you "fall asleep," it's much more of a stretch of time and change of consciousness where your thoughts about doing something become you actually doing it. It's like being able to remember intellectually the taste of chocolate, but a wall of consciousness slowly disappears and you really can taste it.
As you said, though, this isn't usually something you tend to remember.
Your reasoning is incomplete. I believe this legislation is ridiculous and the reasons you mention are directly related to this. (NOTE: This is a response to student's notes, not direct copies of lectures. The latter, I agree, should be a copyright violation, without express consent from the author.)
First, you state "I created the lecture." This is true, but what exactly is a lecture? It's your filtering of ideas (very likely not your own) into a format that can be presented in a short period of time. This can include your own thoughts and insights, but likely the vast majority of information is merely filtered information. (If you by some chance are the third- or forth-sigma professor who is presenting mostly original information, perhaps this does not apply, but I think broad legislation for Given this, you must now present your lecture to students who have paid the university (thus paying you), and who now must do a good deal of mental work for themselves to filter and process the information you've presented in order to understand it. After having paid you for your efforts, why should they be restricted in their efforts?
Let's extend the reasoning here, first backwards. If they are not allowed to profit off the information they've paid you for that you've gathered and processed, why should you be allowed to profit off information the authors of the books and materials you gathered your information from? Likely you didn't pay every author you have on your class bibiography. (You do have a biliography and at least give credit, right?) Libraries, for instance, and the web are wonderful resources. However, as you state, you don't want people making derivative works of your work and profiting from them!
Now let's continue to extend this in the other direction. Now that students have learned from you, after having paid you and done the work to learn, perhaps they shouldn't be able to profit at all! After taking your lecture, they should never be able to work and make money from the concepts they might have learned from your class.
This is of course, ridiculous. The reason we go to a university is to learn so that we, too, can extend our knowledge and someday be able to use it to support ourselves.
The real motive here is monopolization of the flow of information. Students could learn instead by going directly to your sources, but that would be more effort, perhaps an unreasonable effort, so they come to you, and you profit from this, because they are willing to pay. However, some students may be willing to pay for further help and further insight, yet you wish to limit this, because you wish to beh te only source of this information. I find that a rather appalling position for university faculty.
If we wish to completely limit the profitability of information, retain complete control on its flow and on the flow of profit from it, then information will never be able to be used. We are an information-based civilization. The implications are frightening.
Instead of condemning the article which others have done here quite thoroughly, for the better, I'd like to step aside a second and wonder about the potentially good side effects of this report:
Then again, this is probably just asking for more laws to be made, which may not be so good, either.
I'm not a lawyer, or very familiar with how these things might work, so is there anyone who is that might comment?
(This may be moderated down as a troll, or as being flamebait, or whatever, but it should be said. Does it make you uncomfortable? Does it tweak some part of you that says maybe you shouldn't be doing these things? Maybe it should.)
Who cares about ideals! Who cares about individual freedoms and rights! As long as I'm comfortable and entertained, people should just stop whining! Conform! It doesn't matter, after all; besides, relax, sit back, watch a movie, pop some soma, don't worry, and be happy!.
...right. Our rights are being whittled away here. It's not going to stop; it's not even just started: we're in the middle of it. And it's not going to end until we're all restricted by law into being nothing but mass consumers.
The hypocrisy we see here is pretty sad, too. On one hand, it's down with the MPAA, down with Microsoft, down with RIAA, and down those things that take away our freedoms. On the other hand, we see CmdrTaco and other slashdot authors buy DVD's (supporting the MPAA), buy and use Windows (supporting Microsoft), buy CD's (supporting the RIAA), and generally don't take action on their loudly-stated beliefs.
If you believe these things, if you truly support your viewpoints, give up these comforts and frivolities.
You know what? It's perfectly possible. You can find things to do with your time, entertainment or otherwise, instead of wasting it on supporting the things you say you don't support. Try it.
(By the way, DVD's really aren't that much better than VHS. Sure they're more portable, and hold some more data, and you can make exact copies, but average video quality is only slightly better. In many cases, it's even worse.)
And I want you to remember, every time you buy a DVD, you just gave money to the MPAA to support their case. You did. And you told the world that, no matter what you vocalize, you don't really care about your rights. Consider it.
The "last line of defense"? Hardly. See the Functionality missing from MySQL section.
Summary:
MySQL has no referential integrity. (Under some definitions, this excludes it from even being considered a RDBMS.) It certainly lacks PostgreSQL's object-oriented capabilities, which are highly useful, such as table inheritence.
PostgreSQL has all of the above features, and has had them for some time (with the exception of FK's, which are new to 7.0). It is stable and well-tested. MySQL developers are still working on these features. I'd say MySQL has quite a way to go before it reaches PgSQL's "last line of defense".
I didn't mean a natural language for programming, but it might make a "cute" user frontend. As you said, and as I suggested, and "integrated" CLI/GUI. Maybe you don't like that either, I thought it might be kinda neat though, even a "constrained" natural language syntax, especially for new users. Either way, some form of input to do selection and various other things we all know are faster from the command line. ;)
I won't get into a big language discussion here (re: Python). I don't really care for Python, mostly because I find it simply doesn't do anything well enough that something else doesn't do better, or at least as well (not to mention the current implementation has some performance issues). I could go on all day about various features of various languages though. However I'd like to show a little something "cool" about a pure object-oriented system.
First, by a pure system I mean it includes (but is not limited to ;) the following:
This is the "little something": by virtue of unification (point 2), the objects from points 3 and 4 are available to users directly. Now say we have a particular subclass of CodeBlock that is a mere list of method calls, with parameters, to other objects in our system. What we have is a complete "language that isn't a language"! Let me be more specific; we have all the elements of an object-oriented programming language here, but no actual syntax itself. For instance, given "code" such as the following (in whatever horrible crossbreed language this is *grin*):
if(Date::getToday() > "12/13/00") {
new StickyNote n;
n.text = "Your flight leaves tomorrow morning at 6, get packed!";
relate n "on" Desktop;
rename n "Plane trip tomorrow!";
}
or something equally inane (OK so it's after midnight and I can't think of a good example, sue me ;), we can break all this down into nothing but method calls and objects (and a few calls to the object system, which amounts to something similar). For instance, the block between the braces will be a CodeBlock, which has the if(Boolean) method being called on it, which is being passed a parameter that results from the operator> being called on the result of Date::getToday() with the string parameter... well, you get the picture. It's fairly easy to break this all down.
There are some rather neat implications here, and if I just know they're going to scare everyone away because "that's been tried and doesn't work." However unless you've been asleep (as well you might, you might find this dry reading), you probably see them already. One is that all you need is a parser for a given syntax to "translate" into this set of method calls, and you've got (in theory, always in theory ;) "portable," "compiled" code. Since even if you write this in C, you're merely going to be making many of these calls to your object system anyway, for many things performance won't be any different. (Of course, with anything that does tight loops or number crunching, making object system calls for each Integer and Real will likely be a drag. That's why we still can write CodeBlock objects in C, C++, or anything else. ;) Perfectly acceptable for your scripting language, though. And everyone gets their favorite syntax.
The other thing you might find equally horrible is this can be done totally "visually." Just drag a whole bunch of methods and objects together, use arrows to show which goes where, and presto. Same output, no "code". Nice for newbies and such, maybe even to debug visually ("decompiling" these "scripts" is trivial of course), maybe even nice for building the equivalent of those long command-line pipes. Who knows. It'd be pretty cool, for instance, to have a couple separate "boxes" that gather data independently, and then put the results together... easy parallelization here... ;)
Anyway, for those who haven't fled in terror or marked me as mentally disturbed... oh, so no one's left. ;) Well, I hope you at least get a glimmer of the real flexibility that's brought about by such a system. The possibility of a "language that's not a language" isn't meant to turn users into programmers---something not likely to happen---but rather demonstrate another aspect of the inherent beauty and elegance that such a system brings about naturally, by the very nature of its design.
Let's go about this in order:
But how do I distinguish between a text editor and a word processor? How do I distinguish between typing text into the text widget of the gimp and typing text into my text editor and typing it into my word processor?
This immediately assumes an application model already. I know it is quite difficult for you to do otherwise; it is for everyone I talk to, until they switch their thinking around.
Of course, that doesn't answer your question. And before I start, I'd like to say that there were a lot of things I left out in the original. I'll try to cover some more detail and depth this time around. And now for the answer: why would you regularly be opening your word processor or text editor?
To write a document or edit code (likely), of course. In an OO system, you might take a Page object and make a FormattedText frame in it (or likely you'd have a template of this). Or then again, you might just start typing text, and the system would bring up a "text buffer" of sorts you could type in. You could later take this bit of text and put it where you wanted (format it, whatever). That's another way of doing things. There are many possibilities: the important thing, the extremely important thing that you see here, is that you're not just running a program. It may seem similar to you, but the difference is incredibly important. How is it different?
Let's take the first model. You have a Page object. This object has properties such as size, and all it does is contain subclasses of DocumentObject. Each DocumentObject has properties such as size and dpi, and methods such as render(). A Document is nothing more than an ordered set of Pages. There is nothing saying a Document must be text; it might be a drawing, or a musical score, or a combination of the above. Each different thing, such as a MusicStave or Image is just a subclass of DocumentObject, and thus Page wouldn't care. "But, but," I hear you exclaim, "how is this different from OLE or other embedding?"
It is both subtly and enormously different. Subtle because you have similar ends: one sort of medium in another. Enormously because almost everything else is different. There are no applications here; you're not embedding Word in Excel in Explorer in Word in MyPhotoEditor2000. Ask yourself: once you start embedding one application in another, and one changes into the other, why are you bothering with applications at all? Why do they need to be there at all? Of course, they don't. Programmers don't have to go to painful lengths and write horrible hacks to make their programs interact with each other via OLE or CORBA or COM or whatever the latest fad is; they simply write objects, with the simple functionality they contain, and by the nature of the system these objects work together.
Next:
The only way that I can see, short of omniscient computers, is to do something which is the equivalent of launching a program. Calling it changing modes, shifting paradigms, praying to the archangel gabriel. I don't care, but someone, unless this computer is psychic, I have to tell it what I want.
I hope I have in some small way shown why this is not equivalent to launching a program. Telling the computer what you want does not imply programs and applications. Having the computer respond to what you're doing automatically does not imply you won't have to ever tell it what you want. But the difference is extremely important. Oversimplifying is shortsighted, and will continue to lead down the wrong development path until it is corrected.
At that point, you're right back to ./dns2reverse.pl and frankly I don't really believe that you're going to come up with a much faster interface than the command line.
I'm not sure what dns2reverse.pl is, but I have not said or implied that textual input is in any way dead, obsolete, unnecessary, outmoded, outdated, or even less important. The opposite is true. With a proper object-relational system, you can bring textual commands to a new height. A "natural language" like frontend beside a GUI might even be the best and most useful thing for both experienced users and new users alike. What you say next relates to this:
So if we take a step back from input and just focus on file storage, doesn't everyone realize that a filesystem is nothing more than a relational object database?
I don't know if you're oversimplifying or you just don't know what a general relational system is, but a filesystem is merely a very limited form of the relation, that is, containership. The world is not hierarchical. With a true relational system, you could specify that an object is "next to", "over", "under", "inside", "part of", or any other number of relations. Hierarchy is easy to do with this... objects are merely related to containers as being "in" them. However, a more general relation is quite a bit more useful. A document might be "part of" a project, and also "in" something else, perhaps "related" to a different document. A conventional filesystem is not optimized for handling general relations like that.
Back to the textual input interface, though. Once we have established a relational layout, we can easily say things like "show me everything related to Project XYZ." Or, "show me all Graphic objects in reports from last year over 1 megabyte" and get a "query window" that would be similar to your typical icon view of a directory today. All the data is now there and accessible. The possbilities are endless, and the flexibility...
And UNIX even has the object-stream method, more or less (more less than more, in practice). Make every data file you have executable ...
You don't understand what an object is. Go get a good book (there are any number of good books on the subject), and read what encapsulation, polymorphism, inheritance, and abstraction are. They aren't fancy buzzwords; they define what it means to be object-oriented. To back this up, your example lacks encapsulation (the data and functionality aren't bound), inheritance (doesn't even make sense here without encapsulation), polymorphism (no methods or inheritance and nothing to be polymorphic), and abstraction (no context - the data itself is meaningless bits and bytes).
I've got a friend who rants about the everything-is-an-object model once every month or two. The problem with it is that it isn't how life works.
I've looked around, and I can't find anything in "life" that isn't an object. If you can find something that isn't an object (it can't have any properties, for instance), then I'd like to hear about it. Of course, "nothing" might not be an object, but then, if nothing isn't an object, then everything is an object. ;)
But please don't ever make a system which requires you to describe the data that you want by the data that you want rather than some external artificial description. I'd much, much rather use logo7.jpg than "The logo in the burgendy shade of red which is bump-mapped a little more than logo6.jpg and I airbrushed ..."
There's nothing requiring you describe anything. However "logo7.jpg" is hardly descriptive of anything, I'd sure not want you to organize my graphics collection. However, you'd likely want a "title" property (short) and perhaps a "description" or "comment" property where you could expound a little more on the thing, so you could make searching easier...
Oh, and computers do make a difference between code and data.
I did not say that there was no difference. I don't know how you got the impression that I did. (Or is this a straw man? I said they don't force you into a program model; rather they execute code which manipulates data.)
If it was that revolutionary it would have revolutionized by now.
I take it you believe every concept possible has been considered and either implemented or shown useless, and that nothing new and exciting can be done. What a dull world!
New things can be done. New things might even be getting done. We just have to avoid this geezerly "it's been done this way since my gradpa's grandpa and aw say there ain't no other way to do it!" attitude, step way back, and evaluate whether there isn't a more useful way of doing things. For some things, the old way might be the best. For this, programs and applications must be replaced.
This article may purposefully be controversial or not, likely it is. Things that make people think and re-examine current ideas usually are quite controversial.
However, your proposition that a computer is a "device that runs programs" is incorrect, perhaps subtely, but the mistake is very important and the reason the rest of your reasoning is also incorrect. Let's look at this a bit more closely.
First, your statement. At the core, a computer does not run "programs". It executes code, which in turn manipulates data in some fashion (whether moving it to the screen or to a disk, it's data). What's the difference, you ask?
Saying that a computer runs programs presupposes an organizational model, a split between data and functionality. However, a computer doesn't presuppose this at all, as we can see if we examine it at a lower level. "Modern" operating systems, of course, make this supposition, and their underlying model is what "forces" higher levels of activity (developers and users) to also operate under this supposition. In fact, we've been using operating systems that function in this manner for so long that for the most part we all merely assume that the computer itself imposes this model on us. This isn't so! Why is this important?
When someone suggests another model, our assumption that the computer forces us to our current model blinds us to the possibilities, and even the very nature, of the newly-suggested system. As developers we no longer even take the time to consider a better way of doing things. If something needs done, we write as program, because it's programs that get things done! Or so we're lead to believe. So we continue to believe, as we wander further and further down an increasingly difficult path of programs, applications, and files. What's wrong with this path, though?
After all, we've been using programs to do things for us for the most part sice the first computer was built. Old doesn't imply that this is bad, so what's the problem? Computers are a tool. They are meant to be used to aid in whatever we're trying to accomplish, like any other tool, whether this is to write a book, or simply relax to a nice game of Quake 3. Just like any other tool, though, the closer they fit the problem, the better off they are. You want a hammer for a nail, after all. Programs, however, come in two varieties: applications, and utilities. Applications simply don't scale. They grow into larger and larger monstrosities of code, adding whatever new "feature of the week" seems cool to the developer or marketing department, and only interact through kludgery and hacks (such as OLE and related mechanisms). Applications aim "shotgun-style" to hit a broad segment of functionality, and if it doesn't do what you want, you're out of luck. Unix-style utilities on the other hand do a single thing very well, and are typically built to be useful in a chain of interaction (such as a pipe or other redirection). These have problems to, but different ones. Typically they require knowledge of how to get from what you've got to where you're going, that is, which commands will get your data, modify it in the way that you wish, and then output it to where you want. Often they require "data frobbing" along the way to make the next utility understand what the last one said, since the stream of data has no meaning outside what each utility gives it. So what would be better?
An object-oriented (OO) system, as many people have suggested, is really the next step (no pun intended) above a utility-centric system. As I'm sure you know, an OO model reorganizes ("encapsulates") code and data into units ("objects") that, because of the encapsulation, have the implicit meaning which our streams lacked. (They also add a lot of other things I won't go into, because I'm sure you know, and it's not necessary here.) This is not fundamentally different from how a computer works. It is merely a more useful reorganization of what a computer already does, namely, executing code (object methods) and manipulating data (object properties). How is this more useful?
Objects can interact without the problems encountered with utilities, but retain all the advantages. There is no need to worry about how data is formatted so that something else may parse it, but rather each property can be queried directly upon request, when necessary, if necessary. Objects remain independent, focused only on what they do, without growing features out of control to handle every case under the sun. We can use these objects as building blocks to form what we're after: they model every situation we can come across with a great degree of accuracy. How can I make such a broad statement? Look around where you're sitting right now. Your desk, you monitor, keyboard, pens, paper, books, etc. They're all objects. Everything we use and work with is an object already: it's natural. This is another major advantage (and also for some, a disadvantage): we're used to objects. People already know how to work with them. Unfortunately (and here's the disadvantage), we've all been conditioned to working with programs so long, that using objects on the computer seems unnatural. We can't think of any other way of doing things than opening up an application and saving that file. Here's the test though: what happens when you sit someone down who has never used a computer before?
Usually, they want to start typing, or start drawing, or immediately attack their problem at hand. Instead, they have to go through a set of unnatural and unusual steps, like starting up the word processor or drawing program, making a new file (of what type?), and any other number of things, before they can start writing or drawing. And once they've done that, they're not done! They have to save it, which is quite a foreign concept to most (after writing on that piece of paper, do you have to tell it to remember what you just did? I don't think so.) So, how would these common actions work in a totally object-oriented environment?
Instead of starting a program, and making a new document, you might simply grab a piece of paper, and start typing onto it. Or, pick up your tablet (or grab your mouse), and start drawing onto it. The code to decide what tools to present is trivial - if you don't believe me, look at GIMP or any other device-context-aware program. Pick up a tablet stylus and it'll switch properly to the last tool you were using. Same with the mouse, etc. Once you're done? You're done. You wrote that chapter or drew that picture, just put it away. Objects are persistant, and this is natural. But how to restore that change you didn't want to make? Or revert? Undo, and version control. Already been proven to work. But how would "other" things, like Quake, work, in such an environment?
Same way. Each quake level is still composed of objects that do things, have certain methods. Quake levels themselves are "containers" for these objects. Internal representation is up to the implementation of the object. Fast 3D display is for an interface object (a "View") which determines how to display these. (A level editor would be much the same, use the same objects, but present a different view.) Simple, see?
This is important. Hopefully this will cause those of you who chance to read this to stop for a moment and think of the possibilities, and a better way of doing things, and maybe someday we'll even see a system like this.
We don't need 1024 of them. Only 640. After all, 640 is enough for anybody; no one will ever need more than that.
OK, this one was just too hard to resist. I wonder what ERB would think. If NASA's making atmosphere plants, I wonder how long it'll be before we can ressurect Helium and pick a new Jeddak...
Don't count on getting a patent. Too many cases of prior art. :)
*shudder*
See, this movie would have been fine if it had done one thing: not purported itself to be real. Mission to Mars implied that "this is how it really is, no really", when in fact it's obviously a bunch of pseudoscience crap.
Star Wars, on the other hand, is fantasy, fairy tale... not science fiction. It says "what if the world were like this," and "just imagine." This affords a lot more suspension of disbelief.
Remember, in science fiction, the science is supposed to be "right," but everything else is made up. ;)
Yes this looks very interesting, I'll check it out and maybe switch over. Looks like it has a package-management-style interface (epkg) and package "format" without losing the ability to stow any old thing. Very cool!
Any OS that doesn't have symbolic links can... uh, never mind. ;) Are there any unices that don't...? I'm afraid I've only worked with Digital, AIX, Solaris, BSD, and Linux... any widely-used filesystems out there that don't, or any good reason for avoiding them...?
I think supporting non-unices is rather a nonissue, since they tend to be so different that you couldn't have such a scheme generic enough to satisfy them all. Perhaps, though, you could have a system that says "this is a binary, this is a config file", etc., and the backend would install it in the right place. (Like automake, I guess.) For unices with symlinks you'd use a scheme like stow, and for other OS's you'd use something they like.
Dunno.
Actually I really do mean /lib. I did it once, too. :) I wasn't using stow per se, but a little script I had hacked up (before knowing about stow) to do the same thing.
Even if all your stuff is dynamically linked you'll be OK unless you blow away the package directory with libc. (But by that point, you're really screwed, anyway.) For one, your shell probably has built-ins that do things like mkdir, and even if they don't, don't forget about LD_PRELOAD magic.
Just don't have root running a dynamically-linked shell, or don't log out. ;)
Actually all you have to do is make sure stuff is in a properly laid-out format and stow will happily do its magic. (It'll do its magic regardless, you might just have a mess on your hands if it's not proper though. ;)
I could say that naive users shouldn't be administering systems. Maybe I'd even be right in certain contexts. But realistically, new (Linux) users aren't going to be able to compile stuff. (They aren't. When people who can ask questions like "This says, 'error: unable to find freetype, please install it', what does it mean?", you know the total newbies are going to be lost.) Encap as mentioned below (or above I guess depending on your comment ordering ;) might be able to solve this, and allow regular package management without relying on or requiring proprietary formats.
Ports have always sounded pretty cool. But from what I've seen, it's not the complete solution we're talking about (where you put the files, and how you remember what belongs to what, etc.), but then, I haven't really used them, so I'm probably wrong.
(For clarification, I'm a RedHat user at the moment. I've used everything, from building my own system from the ground up, to Slackware, Debian, and even other lesser-used distributions such as Yggdrasil... ;) Package formats such as deb and rpm are proprietary, not in storage format (rpm's use cpio or something), but by composition and requirement. They are composed in a format that is exclusive to their own system of doing things (having specific files in the archive with meta-data about the package). They require their databases and their tools for using. They also require someone specifically construct them. (Waiting for that latest release of XFree86 or some other shiny new thing? Both Debian and RH have at one time or another lagged behind.)
This isn't necessarily bad, it's just rather limiting, and at times frustrating (try extracting a deb or rpm without the proper tools... rpm2cpio, whatever deb has...), but it works. The thing here is that something more generic can be used in the same way.
You're right though. Requiring everyone know how to build from source is going to restrict Linux. But perhaps we can come up with a solution using stow-like methods and a more newbie-friendly frontend (encap maybe?).
Actually stow offers the same advantages as before. You just stick stuff in its own directory, and stow it. If it's not in bin,lib,man etc. format, you can put it that way with little trouble. (For totally problematic packages like StarOffice which just make a big mess, I have a separate /usr/local/packages directory where things go and don't get out-linked. Easy enough to make a menu entry to launch the given application, and keeps things clean.)
Dependencies tend to be a non-issue with autoconf. If you're missing something, it'll tell you what to get and where to get it. Some sort of automation would be nice here, of course. It's certainly possible (look at Perl's CPAN shell), and would make building pretty easy.
It does handle conflicts, though, by telling you there's a conflict. I don't know how else you'd want this handled, but I'm sure any number of schemes could be devised.
Hmm yeah, I think deb's and rpm's both can build from source too. Encap (as mentioned by another poster below) seems to have some of the above mentioned features though. Probably using one of the post-install scripts one could go about running a configuration thing too, but I'd much rather prefer a linuxconf module or something similar.
What needs done is much simpler. Currently popular packaging systems need dumped in favor of GNU Stow. Then we don't need to change automake and autoconf at all, because they work as-is.
Dependencies could be added to Stow by someone without a lot of trouble.
For those who don't want to download and install it to figure out what it does (althoug you should! It makes life very easy if you do any source installs), GNU Stow takes "packages" that have been installed in the standard manner (things placed properly in bin, lib, man, etc.) in their own directories (such as /usr/local/stow/) and makes links to the parent directory's bin, lib, etc. You can tell by a simple ls -l what a file belongs to. Since the links in the directories aren't the "real" files, you can delete and restore them with minimal trouble (I challenge someone with a conventional system to rm -rf /lib and restore it, without rebooting). You can even maintain multiple simultaneous versions of packages. Autoconf already makes this easy to use, simply supply the --prefix= parameter to your configure scripts.
No silly proprietary formats, nor waiting for someone to come out with the latest package in your favorite format, no trying to convert foreign packages to your system. Everything you can find in a tarball is now pre-packaged and waiting for you to install...
Here we have a dilemma, or so it seems. On one side, we have "Linux deserves better marketing". We as Linux users (for those of us that are, and I'm sure there are those reading this who are not) see this and say "yes, it does... I want to use Linux everywhere I work, because (I enjoy it|it makes my life easier|it's fun|it looks pretty|whatever)".
On the other side, we see "It is the acronyms and not the technology that is of prime importance when selling to the corporate server sector." After all, that is what seems to sell and promote OS XYZ over Linux/unix. Then the hackish nature in us reviles, and we imagine ourselves not working on those things that are of importance, those things that are useful, those things that we should do because they are what need doing, and instead work on glitz, paperclips, and TLA's.
And we are right. On both counts. This is not a dilemma, we do not have to "sell our souls" to the corporate nature as this comment would seem to imply. Do we not understand "a new paradigm"? How is it that we have created a new market, a Free and Open Source market, one totally unheard of, yet one totally successful?
Who is it who is unwilling to change? "and nothing you can say will change my mind" Who flames, who insults; who is set in their ways, who unwilling to create a new market where technology does matter, not TLA's and buzzwords?
I suggest we learn. Not to compromise our ideologies in order to conform to a market, not in order to have higher sales and make more money. I suggest we learn what is best, to write software that doesn't mimic poorly, but does its job the way it should. To come up with a better way to market, but not necessarily the old way, not to compromise what has been worked so hard for to escape.
Our marketing and promotion is working. There is a slow, sure change on a level which others cannot compete by covering bugs with glitz. If this can be improved, if it should be improved, we need to come up with a truly new method that doesn't treat those who simply are not trained in our field as dogs, to be "thrown a few buzzword bones to chew on". How dare we insult people who have merely different interests, and have different knowledge circles and goals than we? They trust the journals and articles they read because they do not have any knowledge in which to judge.
Show the difference! Explain the importance! They don't have interest in knowing the difference at a code level, nor need to. But we have something different, something better, we can and should show it as such. Why change what Linux is to match what NT is? What point then is there to move from NT?
And those who are unwilling to change will, unfortunately for them and for us, be left behind. But it is their choice.
Right now it is... but the fact DVD-RAM's are only... let's emphasize ONLY ... $500 or so, probably indicates this won't be cost ineffective for long.
Remember how expensive CDR's used to be? Look how cheap they are now, and how much they've dropped in price.
Now, if the same percentage reduction came about for DVD-RAM's, it'd be cheaper to burn DVD's than CD's. (Do you "burn" DVD's? If they're not ROM's, it must not be permanent... whatever. ;)
And for the most part I didn't mean this for a "home grown piracy job," just people who know they're getting this sort of "self-destructing" media will merely make a copy the first time and throw out the one they bought.
Interesting legal issue there, too... are they agreeing to only own a working copy for X number of days? Or is making a permanent copy legal? Hmm.... IANAL, so I can't comment. ;)
This is silly. People will just get DVD recorders, copy the DVD, and throw out the old one.