The problem isn't Python, it's vi. We all know Emacs is hands-down the superior editor (no, the superior GUI environment -- no, the superior OS). And Emacs matches whitespace in Python code. (It prints a message Closes 'if something:' when you close the block... and probably 20 other ways of dealing with blocks that I don't know the keycodes for).
My impression is that a lot of the real-world use of Smalltalk is for in-house development. I feel I've heard it's particularly popular in financial institutions. Lots of places that are otherwise very boring.
I think you meant to say inspired by the first OO language, Simula. In one speach, Alan Kay said he felt the first case of OO programming he has found was an unnamed sargent in the army, who make a tape-based file system where the first few records of the tape contained procedures on how to access the rest of the records on the tape.
This was something akin to the tape as an object, where you could ask it to do something (by running the programs at the known locations), but it was free to perform your queries as it saw fit.
Ironically, Wirth's B&D style of language design is complete the opposite of Smalltalk's philosophy, which generally trusts the programmer to do the right thing (while allowing them to do the wrong thing), and encourages transparency rather than firm borders. Oberon, Wirth's latest (most minimalistic) language completely annoys me with its utter lack of any sort of coolness. (I kind of liked the Oberon OS's UI, though)
only flaw (contained objects don't know about their containers unless you create an explicit link back to the container...
That's its only flaw? I think Smalltalk has other flaws, but not knowing about containers only makes sense. What if you are contained by several containers? What if you really don't care about your container (and want to save memory)? What if your real container is far away (linked lists)?
No, that's not a feature, or if it is it isn't a feature that fits with Smalltalk.
I think Smalltalk's biggest problem by far is that it's too insular. It's hard to talk with the rest of the world, or interact with what other programs are doing in other environments. That's the price of elegance, I suppose -- purity only comes when you won't sully yourself. But it's hard to work with. The image is a big part of the problem (as much as I think the orthogonal persistence that it implies is cool).
I really love Smalltalk, but I don't actually use it for anything real (even though I often have my choice of languages). The runtime environment is just too limiting (Smalltalk over FTP?)
There has already been work towards this, particularly in the last few months.
distutils fulfills some of the functionality required for a Python CPAN. I think it has reached a state of relative maturity -- it may be asked to do more later, but it does what it needs to well right now.
There has also been some discussion and implementation of methods to describe and upload modules, which would probably be included in distutils or something related when they mature. I think at that point, along with a little infrastructure on the web, Python will have its own little CPAN. I know CPAN does more than this, but not all that much more, and it's something that should be grown into.
I couldn't find what I was really looking for on the subject, but maybe this thread would be a starting place. There's more stuff elsewhere as well. This message (from that thread) gives a nice overview of what's necessary for CPAN, I think. And I guess the whole discussion starts here.
Forget that other guy -- of course Python is interpreted, just like everything else: it all comes down to machine code, which the CPU interprets.
There has been efforts, most notably the (currently inactive, I believe) static typing SIG, which would make it possible to make code that could be efficiently translated to machine code (also known as "compiling"). Static typing is by no means required to translate to machine code, but it would probably make that faster.
An interesting option might be something like Squeak did, with a subset of the language that can be efficiently translated into C (and then compiled). This is something like what the static type SIG was aproaching -- not quite Python, but something that could run in the conventional CPython interpreter, wouldn't necessarily require any knowledge of C or assembly, but could run fast.
Of course, it is also possible to simply compile Python into system code just as it is (well, if someone wrote the compiler). There is nothing that makes Python inherently interpreted. The problem, however, would be in the efficiency of that code. A naive attempt to do this would probably be slower than CPython. OTOH, compilers for Scheme (which have many similar issues as Python) have produced very fast code (on par with C). In particular, Stalin is very fast (though there are others which are very fast as well) -- sometimes faster than C. Python doesn't have any of the huge flaws that languages like, say, Tcl have in this regard. Some operations are difficult in compiled environments -- like getattr or eval -- but they could still be possible, or they could be left out (since much code doesn't use them). OTOH, all the best Python code uses them.
iSmell is gone, and that makes me sad. It would have been amusing to hack. I even had an entrepreneurial idea for it. But I'll never actually do it, so I'll set it free:
Motivation: Dogs spend all day alone, and they are bored and don't have anything to do except be lonely and pee on stuff.
Goal: Keep dogs occupied in some mindless way -- like video games, except that dogs have less brains, so it has to be a really stupid video game.
Problem: Dogs don't seem to enjoy TV much, and they don't even have thumbs.
Solution: Give dogs what they really want -- not visual stimulation, but olfactory stimulation. Using whatever the heck iSmell was going to use, you create a machine that puts out strange and interesting smells. Maybe the dog would have to scratch at it, or maybe a sound would go off and it would emit a smell for a short while. Just give the dogs interesting smells, and just enough other stimulous to keep the smells from getting old.
You could sell little smell cartridges with different smells -- dead animal smells, a variety of urine packs, doggy treats from around the world, etc. -- ensuring future income (as well as variety for the dogs). The smells would all be subtle and difficult for humans to detect.
I think there's money to be made there. Well, at least it's a better business plan than iSmell had.
But I am suspicious. I see no real evidence that electric cars will succede. A lot of effort has gone into them, and while they've had some success it's not very impressive at all.
Without any evidence, why should I believe electric car proponents? Because they say that the benefits of electric cars are self-evident? I don't buy it. There are lots of solid technical reason why electric cars aren't that good. Which side is right? I'm not sure -- the proof is in the implementation. The implementations have been lacking.
So a particular electric car can outperform a Ferrari -- Ferraris are rather lame cars anyway, made for prestige not practicality. Electric cars are all novelty.
Yes, electric cars are a maturing technologies. Many (hell, most) maturing technologies never see the light of day. They are funny novelties that seemed like good ideas.
Fuel cells? Maybe, there seems like some real possibility there. But I'm very suspicious of the battery-powered cars, and I would hope that plans for future transportation, pollution control, and energy use reduction don't depend on electric cars.
1. The pollution by coal for power is dispersed over all electrical equipment. This
equates to a low pollution production versus gasoline having a few appliances outside
the ICE auto for its costs dispersal.
While gas is only used for cars pretty much, that's enough. It's a large enough market to gain all the efficiencies of scale.
2. Hemp endures restrictions around the world via US either directly or indirectly
through sanctions or polices.
Yeah, but that doesn't explain hemp's relative economic unimportance. If hemp was as great as people say it is, then it would be produced more in third world countries -- if only for local use (where restrictions are not common). This US may be powerful, but it's not so powerful that it can put down such a good thing on such a large scale.
3. Places with more pollution and higher engergy costs lack the infrastructure and/or
the resources to change.
Really? China makes their own cars, don't they? They certainly have the ability to build large factories with their own capital. So why didn't they outsmart everyone and build electric cars instead of gas?
4. Japan is an incorrect example. They yield a mass-transit system superior to the US.
There is little need/urgency for electric cars. The population uses rail transportation.
That doesn't explain it either. Japan is still high-density, still uses cars, and has as much ability to produce electric as anyone. Of course, electric cars aren't useful when the vehicles are actually used efficiently, as they are in places like Japan. If the vehicle has to run all day (as with taxis or most fleet vehicles) then electric won't work. If the vehicle has any significant load electric won't work -- and carrying items is something that mass transit does poorly.
Electric cars fill a very specific gap that shouldn't be there anyway -- using a large, complicated machine to move a person a couple times a day.
5. Car manufacturers are behind electric due to policies, force. If it were not for the "oil
crisis" of the seventies, you would be driving gas guzzlers today.
Yes, they are behind electric because they are coerced to do so. Because they are forced to lose money on them, and they've decided they're willing to pay that price.
Some car companies were making efficient cars before the oil crisis! That's a very important distinction. Compact/efficient cars have real advantages, and they existed regardless of the larger efforts that happened with the oil crisis. Electric cars have only imagined advantages -- "imagined" because there aren't any practical implementations. If electric cars made sense we'd see at least a few, real implementations that weren't forced. Then I could stand behind a concerted public effort to force car manufacturers to adopt electric car designs.
As it is, electric cars just look like pipe dreams, and they provide an illusion that keeps people from pursuing more aggressively the real transportation solutions.
Even
an electric car that is recharged entirely from dirty coal power plants still produces ten to a
hundred times less pollutants than a modern car at the end of the day.
Can you provide a reference for that? Really, I'm curious -- I would really love to see a total-system energy-use and pollution comparison between different forms of transportation.
Otherwise I get suspicious. Like, with people who go on about how absolutely great hemp is for everything. Much of the world has no significant restrictions on the production or use of hemp, as far as I know, and if everything that hemp proponents said was true was actually true the rest of the world would be living in a veritable hemp utopia. It makes me suspicious.
I get suspicious about electric cars, too. There are places where these issues matter more than they do to us in the US -- places with more pollution and higher energy costs. Why haven't those places developed these kick-ass electric cars that are so obviously superior to gas cars? Like Japan, say. They are just now making viable electric cars -- and how viable are they, really? I'm not sure -- people aren't buying them left and right, they aren't buying them at all if they aren't someplace where its subsidized (like CA). It makes me suspicious.
Another theory for why car makers have gotten behind electric cars is because they know they will largely fail, and they are okay with that. It will get people off their back for a while, and they will be able to come up with good reasons why they haven't really succeded -- because there are very serious technical issues with electric cars. And if they succede, well, that won't hurt them either -- heck, even if the cars are still significant net polluters, people won't relate them to that because the pollution won't come directly from the electric cars. As long as people don't look to something other than cars. So they give this pipe dream. This might be all silly conspiracy-theory, but the car industry doesn't lead one much reason to trust.
So I eagerly seek an unbiased review of the real effects.
I've often thought it would be interesting to organize a bit of civil disobedience around this. Basically, deliberately buy software with hidden EULA, and demand refunds. Buy the software with a credit card, so you could stop payment when they fail to deliver the service (licensed software) that you payed for. I haven't tried doing this, but I'd be very curious about someone who has. Stopping payment I believe costs them $100 ontop of lost income, and decreases their credit rating (which they deserve). But, if you go into this deliberately you could be accused of buying the software in bad faith... again, I'd be very curious if anyone here has tried this.
I'd also be interested in the legal implications for software that has certain heavy restrictions in the EULA. For instance, software that keeps you from publishing benchmarks. Benchmarks are simply fair use, so it would be allowed in the absence of a EULA. If they (retail store and software producer) aren't willing to live up to the terms of the contract (which means refunding the money), it should be void, and you should be able to use it as though there were no contract.
I assume Oracle would actually give you the license agreement before it took your money (or would give your money back), but more retail-oriented products may not do this (SQL Server? Others?) Might be an interesting way to muck up their systems.
Well, the problem being that a proof of the correctness of a program is only as robust as the correctness of the proof itself; proving the correctness of the proof of the correctness of the program is, well...
I suppose it can be useful to formulate a program in a thoughtful, formalized system. But that's what good code is anyway, so...
many
times I'll see an interesting app on Freshmeat, but it's not Free
Freshmeat has all the information to filter out non-Free or unstable (alpha/beta) software. Right now the interface isn't so great for doing those selections, but that's a much easier thing to fix than getting the data in the first place. (though, I suppose with cooperation from Freshmeat they could simply move all that information over)
You really need to improve the "Why we are not forking Freshmeat!" page. IRC logs are generally indecipherable to me, and that one more than most. If you have something to say, say it.
It also doesn't answer the question: how is Open-Source Directory anything more than a slightly less-Unix, slightly more-OSS, version of Freshmeat? No, they aren't the same, but I fail to see the significant difference. There isWindows software on Freshmeat, and you can view just the Free software, if that's all you are interested in. I'm not worried about OSD dilluting Freshmeat -- mostly because I really don't see why someone would look on OSD instead of Freshmeat, or why someone would post their app there.
You could also push forward a well-organized directory of OSS under the Open Directory... then people would really be likely to see it, even if they didn't know to look for it.
Actually, my gdm (Gnome -- I guess there's probably other G-ish display managers) has a menu option that allows anybody to turn off the computer. I'm happy enough with it. The lack of such a thing on the console login has caused me problems (mostly when someone who doesn't know better turns on the computer and can't figure out how to turn it off properly).
Others have said it differently, but security is a process. Generally, keeping people from turning off the computer when they are sitting at the computer is false security -- something that's merely obnoxious without providing any security benefit.
I kind of wish Linux was wiser about hardware permissions. Anyone who is logged into the console should have complete access to the sound and any removable drives (floppy, CD, etc), and any other peripherals attached to the computer. Anyone else doesn't really need that access. I don't know how one might do that in Linux...?
Maybe a separate group, dedicated to an OSS translator of Word-format
documents, would be sufficient?
AbiWord uses wvWare, which also exists as a fully autonomous application. I've happily used it myself to translate en masse from Word to HTML. I'm sure they would welcome other word processing applications that want to use it for import (or maybe they already are, and I just didn't realize it).
Unlike your analogy, many aspects of DNA are not seperable. There isn't necessarily a sequence of DNA that accounts for every feature (most features?) that we may want. Anything as complicated as DNA is non-linear -- small changes in source can result in large changes in result, and we cannot necessarily deduce from a fixed number of known source->result mappings what all combinations of source will do.
Only with models of what DNA actually does could we (maybe) figure this out. Right now the theory is mostly experimental -- knowledge that when people have done one thing, something else has occured. That's very crude.
An historical analogy might be with semiconductors. Semiconductors are not very complicated -- you add some cyanide to silicon, I believe, and you have a semiconductor that can act as a transistor. But no one thought to do this until their was a model (with quantum mechanics) that would imply that such a combination would have useful behavior. There's no quantum-level manipulation involved in making semiconductors, only quantum-level understanding.
In the same way, we may be able to do nearly everything we'd want to just by manipulating DNA. But we have to understand more than DNA to accomplish what we want.
Hmmm... to explain the nonlinear part: say we have an original DNA sequence of AA (this is entirely abstract). Once you find out what BA and AB do, you may still have no idea what BB does. Understanding what each isolated change does may not give you any understanding of what changes do in combination. To figure out what A and B mean is in many ways simply to figure out how to predict what they will do in combination. And DNA has so many possible combinations...
What Mr. User, Joe wants is something that has either a NIC or a 56k modem (why
pay for both, you'll only use one)
If you have a 56k modem, you might as well put the NIC in there as well. NICs are so simple and cheap, it seems bizarre that they aren't included standard in nearly everything (laptops, desktops, consoles, etc). It's forward-compatible -- except for the possibility of a wireless network, 10/100baseT ethernet seems like the local network standard for a long time to come. Few technologies just work so darn well as ethernet does.
If you want uniformity, you have it already. KDE, Gnome, and CDE all provide uniformity within their desktop environments. If you want uniformity, just run one of those environments. KDE and Gnome both provide a set of applications that should generally fill your needs.
It just happens that you can run both of these at the same time, as well as various miscellaneous applications that have been developed outside any desktop environment. When you do this, it just happens that things are inconsistent.
While I'm quick to blame many things on X, this isn't X's fault. It's a shame that it took so very long for a layer ontop of X to be developed, but it was the (noble) intention of X that such layers be written.
The same is true many places. You can take a BSD kernel and make something that is quite different than your average *nix -- take, for instance, MacOS X. You can take a graphics display and make many interfaces. That's what partitioning and layers of abstraction are all about. Ultimately, I would expect that people will run largely homogenous desktops. I think that is appropriate. And when that happens, there will be consistency.
Having
video drivers and the like run in user space means that your entire local interface can
die while the kernel and its kernel space drivers chug along.
It also means that X can do a DoS on your display. If you can't telnet or ssh into the computer (like, you're not networked, or you don't have a second computer available), this is equivalent to crashing the computer.
X is several orders of magnitude less stable then the rest of Linux. Because X has access to essential hardware without an operating system providing a safe interface, it has the power to crash your computer. It's a total cop-out on the part of Linux kernel developers that they won't include protected video access in the kernel, because as a result Linux is not the high-availability OS they like to believe it is. It is a high-availability server OS, sure, because you don't use X on a server.
Conversely, Berlin programs must work on X11. The graphics can be lousy, very slow,
and plenty of functionality can be missing
Well, that is already handled I think, because Berlin uses GGI as it's display, and GGI can display onto X. This will probably be kind of slow and rather awkward, but it should work.
It seamlessly allows local and remotely-running programs to work together on a
display
This advantage is badly harmed by the fact that X has a very poor security model. I have seldom seen a configuration for displaying on remotely X servers that doesn't involve leaving the X server completely open, which is totally unsafe for general internet use. Especially when you consider that it is easy for a program on X to do a DoS on the server (another security flaw).
Is it such a great feature that you can run X remotely on a LAN behind a firewall? I think it makes sense to shoot a little higher than that.
VNC clients aren't seamless, but they are far more portable and widely available than X and provide better security, as well as session independance. It's not all one might want, but it already beats X for remote display by a long shot.
Re:PSH - because perl is a "real" language
on
To Z Or Not To Z
·
· Score: 2
I've often thought that tclsh could be a decent shell with some interactive features added. Tcl seems to match the semantics that shells require quite nicely -- everything is a string, etc. The quoting rules are more sane than shells usually are. But Tcl seems to be sorely missing some way to expand a list into arguments, which would be important with globbing and such.
Tcl is often considered to be too much of a toy language, but I think as a shell it would actually fit quite nicely. And for all its toyness, it's actually quite elegantly simple and easy to understand.
Slashdot Mirror
The problem isn't Python, it's vi. We all know Emacs is hands-down the superior editor (no, the superior GUI environment -- no, the superior OS). And Emacs matches whitespace in Python code. (It prints a message Closes 'if something:' when you close the block... and probably 20 other ways of dealing with blocks that I don't know the keycodes for).
My impression is that a lot of the real-world use of Smalltalk is for in-house development. I feel I've heard it's particularly popular in financial institutions. Lots of places that are otherwise very boring.
This was something akin to the tape as an object, where you could ask it to do something (by running the programs at the known locations), but it was free to perform your queries as it saw fit.
Ironically, Wirth's B&D style of language design is complete the opposite of Smalltalk's philosophy, which generally trusts the programmer to do the right thing (while allowing them to do the wrong thing), and encourages transparency rather than firm borders. Oberon, Wirth's latest (most minimalistic) language completely annoys me with its utter lack of any sort of coolness. (I kind of liked the Oberon OS's UI, though)
No, that's not a feature, or if it is it isn't a feature that fits with Smalltalk.
I think Smalltalk's biggest problem by far is that it's too insular. It's hard to talk with the rest of the world, or interact with what other programs are doing in other environments. That's the price of elegance, I suppose -- purity only comes when you won't sully yourself. But it's hard to work with. The image is a big part of the problem (as much as I think the orthogonal persistence that it implies is cool).
I really love Smalltalk, but I don't actually use it for anything real (even though I often have my choice of languages). The runtime environment is just too limiting (Smalltalk over FTP?)
distutils fulfills some of the functionality required for a Python CPAN. I think it has reached a state of relative maturity -- it may be asked to do more later, but it does what it needs to well right now.
There has also been some discussion and implementation of methods to describe and upload modules, which would probably be included in distutils or something related when they mature. I think at that point, along with a little infrastructure on the web, Python will have its own little CPAN. I know CPAN does more than this, but not all that much more, and it's something that should be grown into.
I couldn't find what I was really looking for on the subject, but maybe this thread would be a starting place. There's more stuff elsewhere as well. This message (from that thread) gives a nice overview of what's necessary for CPAN, I think. And I guess the whole discussion starts here.
There has been efforts, most notably the (currently inactive, I believe) static typing SIG, which would make it possible to make code that could be efficiently translated to machine code (also known as "compiling"). Static typing is by no means required to translate to machine code, but it would probably make that faster.
An interesting option might be something like Squeak did, with a subset of the language that can be efficiently translated into C (and then compiled). This is something like what the static type SIG was aproaching -- not quite Python, but something that could run in the conventional CPython interpreter, wouldn't necessarily require any knowledge of C or assembly, but could run fast.
Of course, it is also possible to simply compile Python into system code just as it is (well, if someone wrote the compiler). There is nothing that makes Python inherently interpreted. The problem, however, would be in the efficiency of that code. A naive attempt to do this would probably be slower than CPython. OTOH, compilers for Scheme (which have many similar issues as Python) have produced very fast code (on par with C). In particular, Stalin is very fast (though there are others which are very fast as well) -- sometimes faster than C. Python doesn't have any of the huge flaws that languages like, say, Tcl have in this regard. Some operations are difficult in compiled environments -- like getattr or eval -- but they could still be possible, or they could be left out (since much code doesn't use them). OTOH, all the best Python code uses them.
Motivation: Dogs spend all day alone, and they are bored and don't have anything to do except be lonely and pee on stuff.
Goal: Keep dogs occupied in some mindless way -- like video games, except that dogs have less brains, so it has to be a really stupid video game.
Problem: Dogs don't seem to enjoy TV much, and they don't even have thumbs.
Solution: Give dogs what they really want -- not visual stimulation, but olfactory stimulation. Using whatever the heck iSmell was going to use, you create a machine that puts out strange and interesting smells. Maybe the dog would have to scratch at it, or maybe a sound would go off and it would emit a smell for a short while. Just give the dogs interesting smells, and just enough other stimulous to keep the smells from getting old.
You could sell little smell cartridges with different smells -- dead animal smells, a variety of urine packs, doggy treats from around the world, etc. -- ensuring future income (as well as variety for the dogs). The smells would all be subtle and difficult for humans to detect.
I think there's money to be made there. Well, at least it's a better business plan than iSmell had.
But I am suspicious. I see no real evidence that electric cars will succede. A lot of effort has gone into them, and while they've had some success it's not very impressive at all.
Without any evidence, why should I believe electric car proponents? Because they say that the benefits of electric cars are self-evident? I don't buy it. There are lots of solid technical reason why electric cars aren't that good. Which side is right? I'm not sure -- the proof is in the implementation. The implementations have been lacking.
So a particular electric car can outperform a Ferrari -- Ferraris are rather lame cars anyway, made for prestige not practicality. Electric cars are all novelty.
Yes, electric cars are a maturing technologies. Many (hell, most) maturing technologies never see the light of day. They are funny novelties that seemed like good ideas.
Fuel cells? Maybe, there seems like some real possibility there. But I'm very suspicious of the battery-powered cars, and I would hope that plans for future transportation, pollution control, and energy use reduction don't depend on electric cars.
Electric cars fill a very specific gap that shouldn't be there anyway -- using a large, complicated machine to move a person a couple times a day.
Yes, they are behind electric because they are coerced to do so. Because they are forced to lose money on them, and they've decided they're willing to pay that price.Some car companies were making efficient cars before the oil crisis! That's a very important distinction. Compact/efficient cars have real advantages, and they existed regardless of the larger efforts that happened with the oil crisis. Electric cars have only imagined advantages -- "imagined" because there aren't any practical implementations. If electric cars made sense we'd see at least a few, real implementations that weren't forced. Then I could stand behind a concerted public effort to force car manufacturers to adopt electric car designs.
As it is, electric cars just look like pipe dreams, and they provide an illusion that keeps people from pursuing more aggressively the real transportation solutions.
Otherwise I get suspicious. Like, with people who go on about how absolutely great hemp is for everything. Much of the world has no significant restrictions on the production or use of hemp, as far as I know, and if everything that hemp proponents said was true was actually true the rest of the world would be living in a veritable hemp utopia. It makes me suspicious.
I get suspicious about electric cars, too. There are places where these issues matter more than they do to us in the US -- places with more pollution and higher energy costs. Why haven't those places developed these kick-ass electric cars that are so obviously superior to gas cars? Like Japan, say. They are just now making viable electric cars -- and how viable are they, really? I'm not sure -- people aren't buying them left and right, they aren't buying them at all if they aren't someplace where its subsidized (like CA). It makes me suspicious.
Another theory for why car makers have gotten behind electric cars is because they know they will largely fail, and they are okay with that. It will get people off their back for a while, and they will be able to come up with good reasons why they haven't really succeded -- because there are very serious technical issues with electric cars. And if they succede, well, that won't hurt them either -- heck, even if the cars are still significant net polluters, people won't relate them to that because the pollution won't come directly from the electric cars. As long as people don't look to something other than cars. So they give this pipe dream. This might be all silly conspiracy-theory, but the car industry doesn't lead one much reason to trust.
So I eagerly seek an unbiased review of the real effects.
I'd also be interested in the legal implications for software that has certain heavy restrictions in the EULA. For instance, software that keeps you from publishing benchmarks. Benchmarks are simply fair use, so it would be allowed in the absence of a EULA. If they (retail store and software producer) aren't willing to live up to the terms of the contract (which means refunding the money), it should be void, and you should be able to use it as though there were no contract.
I assume Oracle would actually give you the license agreement before it took your money (or would give your money back), but more retail-oriented products may not do this (SQL Server? Others?) Might be an interesting way to muck up their systems.
I suppose it can be useful to formulate a program in a thoughtful, formalized system. But that's what good code is anyway, so...
It also doesn't answer the question: how is Open-Source Directory anything more than a slightly less-Unix, slightly more-OSS, version of Freshmeat? No, they aren't the same, but I fail to see the significant difference. There is Windows software on Freshmeat, and you can view just the Free software, if that's all you are interested in. I'm not worried about OSD dilluting Freshmeat -- mostly because I really don't see why someone would look on OSD instead of Freshmeat, or why someone would post their app there.
You could also push forward a well-organized directory of OSS under the Open Directory... then people would really be likely to see it, even if they didn't know to look for it.
I don't even think OPENSTEP is an OS -- it's the Objective C environment that NeXTSTEP used, ported to other operating systems.
Others have said it differently, but security is a process. Generally, keeping people from turning off the computer when they are sitting at the computer is false security -- something that's merely obnoxious without providing any security benefit.
I kind of wish Linux was wiser about hardware permissions. Anyone who is logged into the console should have complete access to the sound and any removable drives (floppy, CD, etc), and any other peripherals attached to the computer. Anyone else doesn't really need that access. I don't know how one might do that in Linux...?
Only with models of what DNA actually does could we (maybe) figure this out. Right now the theory is mostly experimental -- knowledge that when people have done one thing, something else has occured. That's very crude.
An historical analogy might be with semiconductors. Semiconductors are not very complicated -- you add some cyanide to silicon, I believe, and you have a semiconductor that can act as a transistor. But no one thought to do this until their was a model (with quantum mechanics) that would imply that such a combination would have useful behavior. There's no quantum-level manipulation involved in making semiconductors, only quantum-level understanding.
In the same way, we may be able to do nearly everything we'd want to just by manipulating DNA. But we have to understand more than DNA to accomplish what we want.
Hmmm... to explain the nonlinear part: say we have an original DNA sequence of AA (this is entirely abstract). Once you find out what BA and AB do, you may still have no idea what BB does. Understanding what each isolated change does may not give you any understanding of what changes do in combination. To figure out what A and B mean is in many ways simply to figure out how to predict what they will do in combination. And DNA has so many possible combinations...
It just happens that you can run both of these at the same time, as well as various miscellaneous applications that have been developed outside any desktop environment. When you do this, it just happens that things are inconsistent.
While I'm quick to blame many things on X, this isn't X's fault. It's a shame that it took so very long for a layer ontop of X to be developed, but it was the (noble) intention of X that such layers be written.
The same is true many places. You can take a BSD kernel and make something that is quite different than your average *nix -- take, for instance, MacOS X. You can take a graphics display and make many interfaces. That's what partitioning and layers of abstraction are all about. Ultimately, I would expect that people will run largely homogenous desktops. I think that is appropriate. And when that happens, there will be consistency.
X is several orders of magnitude less stable then the rest of Linux. Because X has access to essential hardware without an operating system providing a safe interface, it has the power to crash your computer. It's a total cop-out on the part of Linux kernel developers that they won't include protected video access in the kernel, because as a result Linux is not the high-availability OS they like to believe it is. It is a high-availability server OS, sure, because you don't use X on a server.
Is it such a great feature that you can run X remotely on a LAN behind a firewall? I think it makes sense to shoot a little higher than that.
VNC clients aren't seamless, but they are far more portable and widely available than X and provide better security, as well as session independance. It's not all one might want, but it already beats X for remote display by a long shot.
Tcl is often considered to be too much of a toy language, but I think as a shell it would actually fit quite nicely. And for all its toyness, it's actually quite elegantly simple and easy to understand.