People dismiss Y2K as a non-event. Something over-hyped and "mostly nonsense".
I work in the power industry, and this attitude really pisses off some of my coworkers who spent thousands of man-hours remediating software and firmware systems one by one.
Yes... Y2K did feature a lot of hype, but the response to the hype saved our ass. Engineers, managers, developers, even politicans... the human race came together on this one.
Makes me think though...wasn't it always implied that computers would save peoples time?
Yes it was. And in a way, computers delivered as promised: they tremendously produced worker productivity. But just because a spreadsheet lets an accountant produce a particular report in 1 hours instead of 8 hours doesn't mean that the boss is going to let him go home at 9 AM. Instead, the boss has fired 7 other accountants and placed all of their work on the one remaining man.
The real question is: are computers delivering as much productivity gain as we think they should be able to? And on that, we still have a ways to go (especially if the ideal is the paperless office [it isn't]).
I can't say that I've given Penrose a fair shake, but my brief review of his arguments implies that they all boil down to the sentimental idea that humans have something indefinably special which cannot be reduced to a set of assembly instructions. His conclusions in The Emperor's New Mind say as much.
It's a curious artifact of the human mind that scientific reductionism is perceived as threatening. Sentimentality and reductionism can co-exist: for instance, I find animals to be amazing things. Yet, animals are the result of a small amount of digital information interacting in a rich enviornment. The information required to define a species can fit comfortably on a CD without compression. Scientist have found ways to manipulate this information. They've had some success with duplicating animals and hacking out new species (glowing goldfish, anyone?). Their techniques are growing all the time, and it's not unreasonable to believe that they will be able to mass-manufacture spare body parts for my grandchildren. I know all of this, but I can still find soaring eagles to be "graceful" and I still find enraged rhinos to be "thunderous/frighteing/overawing". And then when you start to study DNA and how it interacts with the enviornment, you find all of this fascinating emergent behavior that "builds up" in complexity and overwhelms both casual observers and scientist who dedicate their lives to studying it.
Likewise with the mind. If you find it fascinating, it is fascinating, even if you can reduce its behavior to neurons or source code.
And as for the argument from Godel's theorm... the whole point of the theorm is that a formal system cannot recognize it's own Godel sentences. Penrose begins by assuming that "humans can recognize all Godel sentences across all systems", so it is little wonder that he concludes we are not Turing-reducible.
I vote for freezing Penrose's body so that we can brain-scan him when the technology becomes available. Let him reconsider the question when his conciousness is hosted on an x86-derived chipset.
You know, I hate to say it... the problem with Bob wasn't the idea, it was the execution.
No, I'd say that Bob is pretty obviously a concept that is fundamentally and irrevocably flawed. Bob attempted to translate the vast realm of symbolic-information-manipulation tasks down to the narrow realm of interaction-with-everyday-mechanical-artifacts.
Computers are hard. We can do a lot to make them more accessible, but Bob isn't it. You know what else is hard? Learning to read and write. We have all trained for many years to become profficent with this general-purpose communications tool. We haven't tried to invent cuter, more graphical hieroglyphics to tell our stories. We like photographs and diagrams, but text is the predominant encoding for anything serious. When graphics are used for expressing ideas, they tend to become more symbolic and less literal as their design is refined (examples here and here... human writing systems uniformly follow a simliar progression).
Primitive man could doodle a picture of himself spearing a bear. That was sufficent for documenting his exploits, and it was a lot simpler than "learn to read and write". But today, we're willing to pay that price because cave paintings are useless for conveying philosophical insights, complex narratives, and technological explications.
Computers are still very new, but they have opened up for us the world of Turing-complete computation. It is the most generalized tool that mankind has ever invented. You can't reduce it to a set of hyper-literal programs.
Which just goes to show how racist America still is. You just don't get black pop stars if they're not singing hip hop or jazz or some of that other Africian style music.
If anything, Reuben is an instance of the "magical black friend" phenomena (eg., like in the movie "What Dreams May Come"). America is past the point of being overtly racist in polite society. While some sense of "racism" still remains, much of it a matter of people preferring their own culture now.
It's quite wearisome to hear blacks being hyper-sensitive to racism. It's no less wearisome to hear whites saying things like "they will hire him because he's black/asian/hispanic" or "they will hire her because she's both female and black". Maybe there's some validity to each group's complaints, but America really needs to progress to new political discourse... solving problems like urban blight or the drug war will do more to help minorities and, in turn, all Americans.
I use gnugo (for AI) + cgoban (for GUI) for playing against the computer. Quite effective for a Linux-based solution, but many alternatives are out there.
As a beginner playing on small boards (9x9), I find gnugo very frustrating. I worked up to beating it most of the time before I lost interest in the game for a few weeks. When I returned, it kicked my ass again.:-)
As I see it, command lines should be (and are) easier to use because they're more like language.
You need to spend more time watching real users fight with software. I'm a big fan of the CLI, but it's not easy to learn. When I first started using unix and linux several years ago, it would take me a painfully long time to do simple tasks like deleting a bunch of files. Obvious actions (like typing "help") resulted in useless error messages. [I was plesantly surprised to try this out in bash a few minutes ago and find that bash now prints an informative little cheat sheet.] CLI is bad at things like "direct manipulation" and "offering the user a manageable set of clear, well-defined choices".
GUI's are easier to learn, and for people trying to perform incidental tasks, a GUI application is generally a better choice than a CLI. That's not going to change. (Alas... personally, I think unix basics should be part of the elementary school curriculum.)
Then why not have the GUI display the command used to perform a given search, so that the user can gently become acquainted with the syntax?
GUI's for CVS are generally quite good at doing this (WinCVS, Cervisa, LinCVS). It's really just another variation of the idea of provinding a tool that translates instructions into a lower-level "language" that is also ispectable and manipulable by the user (compilers, GUI builders, HTML editors all do this in a way). It's a good trick, and it's not used often enough. Heck, most programs don't even have an architecture where the GUI sits on top of a command line that encloses all of the relevant functionality. (For one thing it's more difficult to design... the GUI has to parse the output of the CLI tool. It's easier just to have a shared library that both CLI and GUI link to.) But still... the CVS design is cool.
The key here, I think, is to provide the user with visibility on how the easy "representation" gets translated to the more powerful representation. For example, the Microsoft Access QBE grid (the query-builder tool) lets you see (and alter) the SQL it generates. That little feature helped me ease into learning SQL several years ago (it was great... I would use the tool to generate the view I needed and then copy paste the resulting SQL into my ASP scripts). Now, naturally, I scorn QBE grids and hammer out huge SQL statements that arbitrarily transform and manipulate data.:-)
The language of computers is a stream of octets that are interpreted as instructions by the processor. That is the only language the computer actually understands.
While I don't necessarily agree with the article, let me make an argument for CLI that might be in line with what the author was suggesting: computers fundamentally understand symbolic instructions... whether they are raw opcodes, a string at the CLI, or gestures in a GUI does not matter to the computer.
Many of the things we humans want to use computers for are symbolic in nature (especially in business applications... not so much in gaming and graphics). So what's the most efficent way to join the user (seeking to automate symbolic tasks) with the computer (which is expecting symbolic instructions)? There is no one right answer here, but text is highly effective because humans have tremendous facilities for language comprehension and expression.
Don't get me wrong: text is difficult to learn (be it CLI, a programming language, or a speciality language). But here's the catch: GUI apps are easier to learn because they limit the functionality of the computer. GUI's blatantly advertise the few options that are available and help the user carry those out with a minimum of fuss.
There a section in The Pragmatic Programmer that compares advanced "Find File" operations with the Windows GUI and the unix 'find' command. The unix command will scale to any obvious need (especially when coupled with xargs, grep, sed, etc.), but you have to get comfortable with a lot of syntax. The Windows GUI optimizes the most common operations, but it can't scale to other needs.
Part of the problem here is the inherent tug-of-war b/t generality and directness. The more flexibility I need, the more complex the application must become. There are a lot of clever tricks that can be used to mitigate this: you can hide advanced functionality, or you c an provide multiple interfaces (e.g., CLI, GUI, and web). You can create tools that provide novices with an easier way to work through common problems (e.g., like with GUI builders or HTML authoring software). A lot of these tricks can work on text too: auto-completion, Bash shell tab completion, intellisense, hyperlinks, and IDE's that are smart enough to parse the code around the cursor point and jump you to the correct place in the documentation (try pressing F1 in VisualStudio.NET sometime).
However, the fundamental catch-22 still exists: the more control you want to have, the smarter you have to be (where smart refers to your expertise with the technology you are working on).
I have considered my nForce boards impossible to install Linux on because I am not willing to spend days downloading, burning, and installing ISOs...
Installation was a pain, but it was manageable. I can't quite remember how I did it though.:-( I think I (1) cross-compiled a patched kernel on another machine; (2) installed bare-bones Debian and Windows, both from CD; (3) transferred the Debianized kernel to the Windows partition; (4) mounted the partition under Linux; (5) installed the new kernel; (6) finish installation using ethernet [which went pretty fast because apt-proxy caches all the Debian packages I download].
If I hadn't been able to install Windows, I could have gotten away with a null modem cable to transfer the kernel...
I find that the most efficient interfaces are never intuitive.
True, but blender does some really tasteless stuff... like dialog boxes where you must click on the left side to decrement the number and on the right side to increment it, all with zero graphical hints. Contrast with interfaces that clearly have an up/down spin button by the number and also allow you to edit it with the keyboard.
If you have a well known product, KEEP THE NAME THE SAME! If there are significant differences, call it something like Mozilla - Accelerated Edition or Mozilla - Basic Edition.
This is a practice known as subbranding, and it's probably a bad thing to do... it dilutes the meaning of the core term "Mozilla". Ideally, you should be offering an array of strongly-branded products, each with its own name. Of course, with Mozilla, there's a problem: the variations of Mozilla aren't all that different from each other... they're all web browsers. Ideally, this variation wouldn't be expressed through branding, but through some options in an installation wizard.
However, open source present an intresting extra twist to normal branding: open source projects need internal branding... e.g., something that appeals to potiental volunteer contributers. For example, I'd much rather work on "Firebird" than "Mozilla Lite". (It's also nice to have a concrete name for your accomplishments instead of saying "I componentized existing code so that the user had more options during installation".) In the beginning of the project, getting this appeal right is presumably more important than creating an external brand that appeals to the masses.
If Mozilla was a corporate project, I'd say they would have done better to not produce any variations: the excess energy should have been spent on developing new products alltogether. However, this mentality doesn't work in the open source world, where the majority of contributers are volunteers. If someone wants to create an intresting variation of a popular product, good for them. Some projects are worth doing just for the satisfaction, even if they never become popular.
If we defied all the laws we didn't like, it wouldn't be much of a civilization, would it?
True, but civilization would never have gotten very far if we didn't challenge authority. Nation-states would never have moved beyond being petty ruled by petty despots, and democracy would still be awaiting proof-of-concept had it not been for some rebellious colonists (as far as the modern would is concerned).
Civil disobediance is not just a moral right, it is sometimes a moral obligation. That's not to say the state should tolerate it, but they should be moderate in the enforcement of law. The way I see it, the rebelliousness of the individual and the arrogance of law help counterbalance each other. If things swing too far either way you end up with anarchy or a police state (and sometimes both).
And those rebellious colonist? They didn't have a majority. British subjects in the new world were split roughly 1/3, 1/3, 1/3 between rebels, Tories, and "don't cares".
--
I'm glad Eve bit that apple... what kinda of race would we be to always take the safe choice?
I welcome anything that potentially keeps money in my pocket.
Don't think of this as a law that's going to save you money on taxes (even though it might). The real benefit of this law is that the federal goverment won't impose stupid taxes (like on bandwidth) that introduce friction on society's abilitity to communicate, cooperate, and computate. When these things are frictionless, the economy is in a much better situation to create real wealth. As an example, consider how local telephone service in the U.S. is billed at a flat rate wheras POTS in many other countries are billed at high per-time rates... this certainly played a role in the U.S.'s rise to power over the past 50 years (especially in terms of how quickly the internet was adopted by home users).
For the best potiential of economic growth, governments should make it as feasible as possible to (1) travel, (2) communicate, and (3) augment our higher brain functions with computers. By preventing the significant overhead that would be introduced with taxing bandwidth, emails, etc., the U.S. government helps these goals, and it also avoids the Turing stickiness of information systems (e.g., hacks like "callback services" which exploit the naievety of tariff-makers).
Which would you prefer: 1) an event that has a 1-in-a-million chance of killing 1 billion people or 2) an event that has a 100% chance of killing 1000 people. Different people will argue for different preferences despite the fact that both events have the same expected value of 1000 people dead.
But the greater tragedy here is that humans would waste a lot of politicial and moral energy making the choice... even though the expected # of dead is the same.:-)
... and I guess that while the media circus was covering this, they would be ignoring more important issues that result in thousands of needless deaths every year [take your pick... there are plenty of them].
I use to fear driving my car more than flying, but lately flying just isn't worth the butt rape I get at the security checkpoint (at least at Atlanta Hartsfield). The whole U.S. approach with cars is rather ludicrous though: masses of untrained drivers--distracted by the pressures of everyday life--hurtling past each other in multi-ton vehicles. I think there are about 18,000 vehical-related deaths per year in the U.S. It would be nice to see miles/death statistics of various transportation modes.
Just remember that you have to make sure that all your contracts and legal structure reinforce your power and control, and it's often better to give up some extra equity in exchange for this. Be careful who you trust.
Be that as it may, this is a damn good reason to never even start a business. The law may provide some sort of technical "level playing field" and enforce some technical definition of "fairness", but it's far too techincal for most people to understand all of the intricacies and implications: thus it is pragmatically unfair. And society misses out because discouraged entrepreneurs never make it to the market.
I guess there's an analogy here with computers: I'm Woz enough to maintain my home network and address issues like virus protection, data backup, IP address allocation, security policy, bandwidth utilization, NFS/NIS/Samba, custom kernels for each machine, etc. I can deal with hardware failures; I can find/install any OS or software that I need; I can keep my applications upgraded (apt-get!); I can troubleshoot software issues. The point is: I can do all of this stuff to "keep the lights on" as far as my computing needs are concerned. I'm adequately prepared to deal with most mishaps that could occur. But the average user isn't: they shy away, or they stumble along and get screwed by whatever virus, spyware, hardware failure, $89 CompUSA diagnostic fee, or chronic software glitch comes their way.
The main resource that space missions use up is money. Of course this money would be much better spent on education, health and infrastructure.
Money doesn't matter too much, if they are spending it internal to their own economy. What India will be spending is its potiential: natural resources, labor, energy, etc. Is this the best investment for them? I doubt it, but the prestige might be good for importing businesses and exporting culture... and hey... space travel is cool.:-)
If the same mentality of "efficiency is everything" that was necessary during the days of limited hardware power was voluntarily adopted today... well... imagine Windows XP starting up in one second (and not crashing).
Efficency is everything... but what's more scarce: memory or labor? Consider that 2 hours labor == 1 Gig RAM... in the early 90's that ratio was more like 2 hours labor == 4 MB RAM. Ten years ago, I had to endlessly fuss over the exact combination of extensions and control panels my Mac IIsi and Mac Classic would boot up with. Today, it wouldn't make any sense for me to delibrate whether or not I could afford the memory footprint of all the little startup programs on my PC... it's a non-issue. The analogy carries over to programming: while I could write a really swift C program to process a 5 meg text file buffer by buffer before writing the results to a database through a raw socket, I prefer to use a nice garbage collecting, virtual-machine based OO language to suck the entire file into memory and process it all at once. Sloppy, but it saves time for me and future maintainers.
My point is not that we have it easier or that we can laugh off issues of efficency because hardware is cheap. My point is that, with the change in technology, it is most cost-effective to be addressing other problems. How do we make software robust and ensure uptime? How do we cleanly integrate disparate data systems w/o the whole thing becoming a maintainability nightmare? How do we make it secure and usable at the same time? Whether the software takes a full CD or a mini-CD is not a pressing issue with most software development managers.
This is just like any other resource management problem: in general, you should spend your capital optimizing for the resources that are scarce, not the ones that are abundant... and for most apps, space and time efficency is yesterday's problem.
The parent post does deserve some credit though... efficency is more important than your college professors would have you believe. Sometimes every little byte and CPU cycle really does count (especially when dealing with embedded systems, RTOS, or other low-level software). Efficency is also nice (and sometimes critical) for usability: an effecient GUI is a snappy, responsive GUI. Imagine how much better Java might have done in the consumer market if AWT and Swing did not run like molasses during their early years of use. And let's not forget the command line interface, which--for all the power it provides--is very efficent on space, time, network, and screen resources.
Efficency has its place, but it's no longer the top concern. And of course... every problem is different.
They should really just do asphyxiation by nitrous oxide.
Good point... you could give it a very American theme by modifying an SUV so that the wheels don't spin and the exhaust gets redirected to the airtight cabin. The condemned would get to sit in the driver's seat and "drive off into the afterlife"...
Hmm... gives a new meaning to "falling asleep at the wheel".:-)
I see intelligence (and sentience/conciousness) as a form of computation, just as evolution is a type of computation. We have some rough models that would allow us to recognize evolution, but I'm not aware of any similar models for conciousness.
A couple billion humans may be able to perform the same calculations of conciousness on a large scale that your brain cells perform on a smaller scale... this is not necessarily incompatible with your claim that we are reverting to pack instincts: the struggle b/t individualism and group instincts might be characteristic of intelligent systems. (In humans at least, it seems that different inference sub-systems can produce conflicting intuitions [especially emotional ones] that violently clash, resulting in confusion, stress, and mental dissonance.)
This article reminds me of Bruce Sterling's Distraction, in which a mob spontaneously forms to attack and overrun a corrupt bank w/o any apparent source of centralized organization or communication.
It makes me wonder if we are on the verge of creating a trans-human intelligence capable of consciousness. Too bad we don't have any formal idea of what intelligence and conciousness is, or we could analyze the situation more closely...
That's not a word, that's 40 words. Or 50 words if you'd remembered to put the 'and's in, as per standard number-reading conventions. (55 if you count hyphenations as two words.)
You may be following a different convention, but in the Saxon textbooks I used during middle school, the 'and' could only appear when introducing the fractional part (e.g., 3 million, two hundred, and 4 thousandths [3000200.004]). We did a lot of those word-expansion exercises.
Colloquially, more 'and's are inserted, but in formal communications I've always seen (and used) the saxon convention.
It's quite easy to believe that this is something that varies a lot across linguistic regions. Anybody know of any governing standards for mapping numbers to names? Somebody has to have formalized this.
Re:Don't think so....
on
Qt On DirectFB
·
· Score: 2, Interesting
And so far as the "features" of X... the only feature X has that DirectFB doesn't is network independence, which very few users need, and those who do can use VNC or the DirectFB X server.
If anything, I want to see X11 incorporate more network saavy features... not remove them. It would be nice, for instance, to park X11 sessions and applications, much like screen allows you to multiplex terminals. (There are apps like xmove and others, but none of them are reliable enough yet to withstand X server reboots.) I'd also like to see more RDP-ish functionality (Microsoft's RDP protocal lets you carry sound and printer connections over the network as well). And more flexiblity when working with different screen depths and other resources would be nice too.
Getting back to your point... a frequent piece of design advice is to "optimize the common case". Yes, cutting out network independence does help performance for the common case, but consider: for many, network independence is a must-have feature. It provides all sorts of flexibility with different hardware arrangements and usage models. Thin-client protocals like VNC are nice, but they don't cut it for serious, extended use. And the DirectFB X server isn't going to provide a whole lot of network independence if developers are targeting DirectFB.
The true promise of network independence is only now being realized: it opens up new avenues, even for users who have been content with the "single PC, single desktop" model. It would be a shame to lose the network conveniences provided by X now that we have computers fast enough to host it.:-)
Yes, it would be nice to optimize the common case, but cutting network independence is the wrong way to do it: ideally, the client librarys should be able to choose b/t listening on the network and connecting via shared memory (if X doesn't already have an extension for that [Xshm?]). This choice should be done by the library so that all apps written for X11 are network-capable by default. If the programmer knows they are doing something intensive, then they should be able to do something special to insist on a non-networked app, but this should be the exception and not the rule (and I think X11 has extensions for this too [DRI? xv?]).
Slashdot Mirror
I work in the power industry, and this attitude really pisses off some of my coworkers who spent thousands of man-hours remediating software and firmware systems one by one.
Yes... Y2K did feature a lot of hype, but the response to the hype saved our ass. Engineers, managers, developers, even politicans... the human race came together on this one.
Yes it was. And in a way, computers delivered as promised: they tremendously produced worker productivity. But just because a spreadsheet lets an accountant produce a particular report in 1 hours instead of 8 hours doesn't mean that the boss is going to let him go home at 9 AM. Instead, the boss has fired 7 other accountants and placed all of their work on the one remaining man.
The real question is: are computers delivering as much productivity gain as we think they should be able to? And on that, we still have a ways to go (especially if the ideal is the paperless office [it isn't]).
It's a curious artifact of the human mind that scientific reductionism is perceived as threatening. Sentimentality and reductionism can co-exist: for instance, I find animals to be amazing things. Yet, animals are the result of a small amount of digital information interacting in a rich enviornment. The information required to define a species can fit comfortably on a CD without compression. Scientist have found ways to manipulate this information. They've had some success with duplicating animals and hacking out new species (glowing goldfish, anyone?). Their techniques are growing all the time, and it's not unreasonable to believe that they will be able to mass-manufacture spare body parts for my grandchildren. I know all of this, but I can still find soaring eagles to be "graceful" and I still find enraged rhinos to be "thunderous/frighteing/overawing". And then when you start to study DNA and how it interacts with the enviornment, you find all of this fascinating emergent behavior that "builds up" in complexity and overwhelms both casual observers and scientist who dedicate their lives to studying it.
Likewise with the mind. If you find it fascinating, it is fascinating, even if you can reduce its behavior to neurons or source code.
And as for the argument from Godel's theorm... the whole point of the theorm is that a formal system cannot recognize it's own Godel sentences. Penrose begins by assuming that "humans can recognize all Godel sentences across all systems", so it is little wonder that he concludes we are not Turing-reducible.
I vote for freezing Penrose's body so that we can brain-scan him when the technology becomes available. Let him reconsider the question when his conciousness is hosted on an x86-derived chipset.
No, I'd say that Bob is pretty obviously a concept that is fundamentally and irrevocably flawed. Bob attempted to translate the vast realm of symbolic-information-manipulation tasks down to the narrow realm of interaction-with-everyday-mechanical-artifacts.
Computers are hard. We can do a lot to make them more accessible, but Bob isn't it. You know what else is hard? Learning to read and write. We have all trained for many years to become profficent with this general-purpose communications tool. We haven't tried to invent cuter, more graphical hieroglyphics to tell our stories. We like photographs and diagrams, but text is the predominant encoding for anything serious. When graphics are used for expressing ideas, they tend to become more symbolic and less literal as their design is refined (examples here and here... human writing systems uniformly follow a simliar progression).
Primitive man could doodle a picture of himself spearing a bear. That was sufficent for documenting his exploits, and it was a lot simpler than "learn to read and write". But today, we're willing to pay that price because cave paintings are useless for conveying philosophical insights, complex narratives, and technological explications.
Computers are still very new, but they have opened up for us the world of Turing-complete computation. It is the most generalized tool that mankind has ever invented. You can't reduce it to a set of hyper-literal programs.
If anything, Reuben is an instance of the "magical black friend" phenomena (eg., like in the movie "What Dreams May Come"). America is past the point of being overtly racist in polite society. While some sense of "racism" still remains, much of it a matter of people preferring their own culture now.
It's quite wearisome to hear blacks being hyper-sensitive to racism. It's no less wearisome to hear whites saying things like "they will hire him because he's black/asian/hispanic" or "they will hire her because she's both female and black". Maybe there's some validity to each group's complaints, but America really needs to progress to new political discourse... solving problems like urban blight or the drug war will do more to help minorities and, in turn, all Americans.
As a beginner playing on small boards (9x9), I find gnugo very frustrating. I worked up to beating it most of the time before I lost interest in the game for a few weeks. When I returned, it kicked my ass again. :-)
You need to spend more time watching real users fight with software. I'm a big fan of the CLI, but it's not easy to learn. When I first started using unix and linux several years ago, it would take me a painfully long time to do simple tasks like deleting a bunch of files. Obvious actions (like typing "help") resulted in useless error messages. [I was plesantly surprised to try this out in bash a few minutes ago and find that bash now prints an informative little cheat sheet.] CLI is bad at things like "direct manipulation" and "offering the user a manageable set of clear, well-defined choices".
GUI's are easier to learn, and for people trying to perform incidental tasks, a GUI application is generally a better choice than a CLI. That's not going to change. (Alas... personally, I think unix basics should be part of the elementary school curriculum.)
GUI's for CVS are generally quite good at doing this (WinCVS, Cervisa, LinCVS). It's really just another variation of the idea of provinding a tool that translates instructions into a lower-level "language" that is also ispectable and manipulable by the user (compilers, GUI builders, HTML editors all do this in a way). It's a good trick, and it's not used often enough. Heck, most programs don't even have an architecture where the GUI sits on top of a command line that encloses all of the relevant functionality. (For one thing it's more difficult to design... the GUI has to parse the output of the CLI tool. It's easier just to have a shared library that both CLI and GUI link to.) But still... the CVS design is cool.
The key here, I think, is to provide the user with visibility on how the easy "representation" gets translated to the more powerful representation. For example, the Microsoft Access QBE grid (the query-builder tool) lets you see (and alter) the SQL it generates. That little feature helped me ease into learning SQL several years ago (it was great... I would use the tool to generate the view I needed and then copy paste the resulting SQL into my ASP scripts). Now, naturally, I scorn QBE grids and hammer out huge SQL statements that arbitrarily transform and manipulate data. :-)
While I don't necessarily agree with the article, let me make an argument for CLI that might be in line with what the author was suggesting: computers fundamentally understand symbolic instructions... whether they are raw opcodes, a string at the CLI, or gestures in a GUI does not matter to the computer.
Many of the things we humans want to use computers for are symbolic in nature (especially in business applications... not so much in gaming and graphics). So what's the most efficent way to join the user (seeking to automate symbolic tasks) with the computer (which is expecting symbolic instructions)? There is no one right answer here, but text is highly effective because humans have tremendous facilities for language comprehension and expression.
Don't get me wrong: text is difficult to learn (be it CLI, a programming language, or a speciality language). But here's the catch: GUI apps are easier to learn because they limit the functionality of the computer. GUI's blatantly advertise the few options that are available and help the user carry those out with a minimum of fuss.
There a section in The Pragmatic Programmer that compares advanced "Find File" operations with the Windows GUI and the unix 'find' command. The unix command will scale to any obvious need (especially when coupled with xargs, grep, sed, etc.), but you have to get comfortable with a lot of syntax. The Windows GUI optimizes the most common operations, but it can't scale to other needs.
Part of the problem here is the inherent tug-of-war b/t generality and directness. The more flexibility I need, the more complex the application must become. There are a lot of clever tricks that can be used to mitigate this: you can hide advanced functionality, or you c an provide multiple interfaces (e.g., CLI, GUI, and web). You can create tools that provide novices with an easier way to work through common problems (e.g., like with GUI builders or HTML authoring software). A lot of these tricks can work on text too: auto-completion, Bash shell tab completion, intellisense, hyperlinks, and IDE's that are smart enough to parse the code around the cursor point and jump you to the correct place in the documentation (try pressing F1 in VisualStudio.NET sometime).
However, the fundamental catch-22 still exists: the more control you want to have, the smarter you have to be (where smart refers to your expertise with the technology you are working on).
Installation was a pain, but it was manageable. I can't quite remember how I did it though. :-( I think I (1) cross-compiled a patched kernel on another machine; (2) installed bare-bones Debian and Windows, both from CD; (3) transferred the Debianized kernel to the Windows partition; (4) mounted the partition under Linux; (5) installed the new kernel; (6) finish installation using ethernet [which went pretty fast because apt-proxy caches all the Debian packages I download].
If I hadn't been able to install Windows, I could have gotten away with a null modem cable to transfer the kernel...
True, but blender does some really tasteless stuff... like dialog boxes where you must click on the left side to decrement the number and on the right side to increment it, all with zero graphical hints. Contrast with interfaces that clearly have an up/down spin button by the number and also allow you to edit it with the keyboard.
This is a practice known as subbranding, and it's probably a bad thing to do... it dilutes the meaning of the core term "Mozilla". Ideally, you should be offering an array of strongly-branded products, each with its own name. Of course, with Mozilla, there's a problem: the variations of Mozilla aren't all that different from each other... they're all web browsers. Ideally, this variation wouldn't be expressed through branding, but through some options in an installation wizard.
However, open source present an intresting extra twist to normal branding: open source projects need internal branding... e.g., something that appeals to potiental volunteer contributers. For example, I'd much rather work on "Firebird" than "Mozilla Lite". (It's also nice to have a concrete name for your accomplishments instead of saying "I componentized existing code so that the user had more options during installation".) In the beginning of the project, getting this appeal right is presumably more important than creating an external brand that appeals to the masses.
If Mozilla was a corporate project, I'd say they would have done better to not produce any variations: the excess energy should have been spent on developing new products alltogether. However, this mentality doesn't work in the open source world, where the majority of contributers are volunteers. If someone wants to create an intresting variation of a popular product, good for them. Some projects are worth doing just for the satisfaction, even if they never become popular.
For more on branding, see The 22 Immutable Laws of Branding. Especially items 10, 14, and 15.
True, but civilization would never have gotten very far if we didn't challenge authority. Nation-states would never have moved beyond being petty ruled by petty despots, and democracy would still be awaiting proof-of-concept had it not been for some rebellious colonists (as far as the modern would is concerned).
Civil disobediance is not just a moral right, it is sometimes a moral obligation. That's not to say the state should tolerate it, but they should be moderate in the enforcement of law. The way I see it, the rebelliousness of the individual and the arrogance of law help counterbalance each other. If things swing too far either way you end up with anarchy or a police state (and sometimes both).
And those rebellious colonist? They didn't have a majority. British subjects in the new world were split roughly 1/3, 1/3, 1/3 between rebels, Tories, and "don't cares".
--
I'm glad Eve bit that apple... what kinda of race would we be to always take the safe choice?
Don't think of this as a law that's going to save you money on taxes (even though it might). The real benefit of this law is that the federal goverment won't impose stupid taxes (like on bandwidth) that introduce friction on society's abilitity to communicate, cooperate, and computate. When these things are frictionless, the economy is in a much better situation to create real wealth. As an example, consider how local telephone service in the U.S. is billed at a flat rate wheras POTS in many other countries are billed at high per-time rates... this certainly played a role in the U.S.'s rise to power over the past 50 years (especially in terms of how quickly the internet was adopted by home users).
For the best potiential of economic growth, governments should make it as feasible as possible to (1) travel, (2) communicate, and (3) augment our higher brain functions with computers. By preventing the significant overhead that would be introduced with taxing bandwidth, emails, etc., the U.S. government helps these goals, and it also avoids the Turing stickiness of information systems (e.g., hacks like "callback services" which exploit the naievety of tariff-makers).
For that matter, a little brown pebble could whizz past this little blue one, and nobody would really notice as billions died instantenously.
But the greater tragedy here is that humans would waste a lot of politicial and moral energy making the choice... even though the expected # of dead is the same. :-)
I use to fear driving my car more than flying, but lately flying just isn't worth the butt rape I get at the security checkpoint (at least at Atlanta Hartsfield). The whole U.S. approach with cars is rather ludicrous though: masses of untrained drivers--distracted by the pressures of everyday life--hurtling past each other in multi-ton vehicles. I think there are about 18,000 vehical-related deaths per year in the U.S. It would be nice to see miles/death statistics of various transportation modes.
Be that as it may, this is a damn good reason to never even start a business. The law may provide some sort of technical "level playing field" and enforce some technical definition of "fairness", but it's far too techincal for most people to understand all of the intricacies and implications: thus it is pragmatically unfair. And society misses out because discouraged entrepreneurs never make it to the market.
I guess there's an analogy here with computers: I'm Woz enough to maintain my home network and address issues like virus protection, data backup, IP address allocation, security policy, bandwidth utilization, NFS/NIS/Samba, custom kernels for each machine, etc. I can deal with hardware failures; I can find/install any OS or software that I need; I can keep my applications upgraded (apt-get!); I can troubleshoot software issues. The point is: I can do all of this stuff to "keep the lights on" as far as my computing needs are concerned. I'm adequately prepared to deal with most mishaps that could occur. But the average user isn't: they shy away, or they stumble along and get screwed by whatever virus, spyware, hardware failure, $89 CompUSA diagnostic fee, or chronic software glitch comes their way.
Money doesn't matter too much, if they are spending it internal to their own economy. What India will be spending is its potiential: natural resources, labor, energy, etc. Is this the best investment for them? I doubt it, but the prestige might be good for importing businesses and exporting culture... and hey... space travel is cool. :-)
Efficency is everything... but what's more scarce: memory or labor? Consider that 2 hours labor == 1 Gig RAM... in the early 90's that ratio was more like 2 hours labor == 4 MB RAM. Ten years ago, I had to endlessly fuss over the exact combination of extensions and control panels my Mac IIsi and Mac Classic would boot up with. Today, it wouldn't make any sense for me to delibrate whether or not I could afford the memory footprint of all the little startup programs on my PC... it's a non-issue. The analogy carries over to programming: while I could write a really swift C program to process a 5 meg text file buffer by buffer before writing the results to a database through a raw socket, I prefer to use a nice garbage collecting, virtual-machine based OO language to suck the entire file into memory and process it all at once. Sloppy, but it saves time for me and future maintainers.
My point is not that we have it easier or that we can laugh off issues of efficency because hardware is cheap. My point is that, with the change in technology, it is most cost-effective to be addressing other problems. How do we make software robust and ensure uptime? How do we cleanly integrate disparate data systems w/o the whole thing becoming a maintainability nightmare? How do we make it secure and usable at the same time? Whether the software takes a full CD or a mini-CD is not a pressing issue with most software development managers.
This is just like any other resource management problem: in general, you should spend your capital optimizing for the resources that are scarce, not the ones that are abundant... and for most apps, space and time efficency is yesterday's problem.
The parent post does deserve some credit though... efficency is more important than your college professors would have you believe. Sometimes every little byte and CPU cycle really does count (especially when dealing with embedded systems, RTOS, or other low-level software). Efficency is also nice (and sometimes critical) for usability: an effecient GUI is a snappy, responsive GUI. Imagine how much better Java might have done in the consumer market if AWT and Swing did not run like molasses during their early years of use. And let's not forget the command line interface, which--for all the power it provides--is very efficent on space, time, network, and screen resources.
Efficency has its place, but it's no longer the top concern. And of course... every problem is different.
Good point... you could give it a very American theme by modifying an SUV so that the wheels don't spin and the exhaust gets redirected to the airtight cabin. The condemned would get to sit in the driver's seat and "drive off into the afterlife"...
Hmm... gives a new meaning to "falling asleep at the wheel". :-)
I see intelligence (and sentience/conciousness) as a form of computation, just as evolution is a type of computation. We have some rough models that would allow us to recognize evolution, but I'm not aware of any similar models for conciousness.
A couple billion humans may be able to perform the same calculations of conciousness on a large scale that your brain cells perform on a smaller scale... this is not necessarily incompatible with your claim that we are reverting to pack instincts: the struggle b/t individualism and group instincts might be characteristic of intelligent systems. (In humans at least, it seems that different inference sub-systems can produce conflicting intuitions [especially emotional ones] that violently clash, resulting in confusion, stress, and mental dissonance.)
It makes me wonder if we are on the verge of creating a trans-human intelligence capable of consciousness. Too bad we don't have any formal idea of what intelligence and conciousness is, or we could analyze the situation more closely...
You may be following a different convention, but in the Saxon textbooks I used during middle school, the 'and' could only appear when introducing the fractional part (e.g., 3 million, two hundred, and 4 thousandths [3000200.004]). We did a lot of those word-expansion exercises.
Colloquially, more 'and's are inserted, but in formal communications I've always seen (and used) the saxon convention.
It's quite easy to believe that this is something that varies a lot across linguistic regions. Anybody know of any governing standards for mapping numbers to names? Somebody has to have formalized this.
If anything, I want to see X11 incorporate more network saavy features... not remove them. It would be nice, for instance, to park X11 sessions and applications, much like screen allows you to multiplex terminals. (There are apps like xmove and others, but none of them are reliable enough yet to withstand X server reboots.) I'd also like to see more RDP-ish functionality (Microsoft's RDP protocal lets you carry sound and printer connections over the network as well). And more flexiblity when working with different screen depths and other resources would be nice too.
Getting back to your point... a frequent piece of design advice is to "optimize the common case". Yes, cutting out network independence does help performance for the common case, but consider: for many, network independence is a must-have feature. It provides all sorts of flexibility with different hardware arrangements and usage models. Thin-client protocals like VNC are nice, but they don't cut it for serious, extended use. And the DirectFB X server isn't going to provide a whole lot of network independence if developers are targeting DirectFB.
The true promise of network independence is only now being realized: it opens up new avenues, even for users who have been content with the "single PC, single desktop" model. It would be a shame to lose the network conveniences provided by X now that we have computers fast enough to host it. :-)
Yes, it would be nice to optimize the common case, but cutting network independence is the wrong way to do it: ideally, the client librarys should be able to choose b/t listening on the network and connecting via shared memory (if X doesn't already have an extension for that [Xshm?]). This choice should be done by the library so that all apps written for X11 are network-capable by default. If the programmer knows they are doing something intensive, then they should be able to do something special to insist on a non-networked app, but this should be the exception and not the rule (and I think X11 has extensions for this too [DRI? xv?]).
I saw MacGuyver do this once and he didn't need any stinking laser beams... I forgot how he supposedly did it, but it sure was cool.
He used a standard Air Force pen-knife and some twine provided by the Asgard.