I'm surprised to only see one link to Bogofilter in this discussion. I started using it just a couple days ago, training it from scratch (because I am patient and lazy). I train it on all emails it doesn't mark as spam, and then retrain it on spam it misses. So far I'm up to catching about 50%-75% of spams (climbing rapidly), with one false positive (though I had to read through that email a couple times to realize it wasn't really a spam -- so the false positive is understandable, since as a human I could have made the same mistake).
Bogomail potentially captures more relevent words than as described by Graham -- IP addresses, email addresses, and other text that should be considered atomic are recorded atomically. I think even more could be done with this -- but I worry that bogofilter is going to create too large a database, as it even seems to be keeping track of words like "$20".
As an optimization, I could imagine you could double-register some words, mostly those in headers. So the word "mother" in a subject line might register both "mother" and "subject:mother". Perhaps IP addresses could be recorded with all their classes (e.g., "200.69.228.105" would be recorded as "200.69.228.105", "200.69.228", "200.69" and "200" -- maybe prefixing some text to the last three, so that "200" the number is distinguishabe from "200" the class-A address)
Ultimately, a well trained spam database could be trimmed and distributed, but bogofilter does not yet include such a database. Graham's concern about distribution and trust are, IMHO, not entirely necessary -- a well-trained database can be created by only a handful of people (who receive lots of spam), and even if non-spam must be classified on an individual basis, spam is not tailored to any individual (nearly by definition). I don't think this has as great a risk of censorship as blocking lists.
I would be interested to see an improvement in the client end of bogofilter (or similar software). Right now I'm using procmail, and forwarding miscategorizations back to myself with a changed subject line (which procmail catches and feeds to bogomail). With just a little work, this could be used to create filters besides spam, where I train bogofilter to filter based on other criteria. (Well, I can do this right now, but it would take only a little work to make this accessible even to computer novices)
Forgive me if I'm wrong (or better, correct me)... but I didn't think Plan9 did this sort of thing. At least, not the file metadata, or plugin interfaces to files. It just placed a number of kernel interfaces into the filesystem. There's no (significant) reference to "metadata" in that document, and in one instance where they are talking about permissions, they are talking about using chmod on a process, but not the more novel echo newGroupOwner >/processes/processID/group
I think what Reiser is talking about could be truly novel -- I'm sure someone has thought of it before, but I don't know that anyone's made it happen in a real OS. (Though I wouldn't be surprised to see it in an experimental OS)
Assembly language should be the FIRST thing taught, and then gradually building up to higher and higher levels of abstraction.
Assembly isn't necessarily the most fundamental level. Sure, it is for one particular computer (in a way -- pure machine code is slightly more fundamental). But you can go lower, if you see it as a mathematical, not electrical, excercise. Maybe the first two years should be taught using Turing Machines, or with the lambda calculus?
Other people might feel that Forth was a better language -- having just enough abstraction to allow some modularity, but only barely. Nearly all virtual machines look like Forth machines... I suppose that implies that computer scientists disagree with electrical engineers as to how a machine should act.
Number 2 and number 4 are simply not true (especially number 4). Electric motors are an extremely mature technology, vastly more reliable and flexible than gasoline engines in every way.
All the blame should go to the batteries. None of it need go to the motors.
They say it generates "30 percent less waste", which I assume means operational power, though it could mean construction waste. Electricity used for automation is trivial compared to things like lights, dishwashers, air conditioners, or hair dryers. We're not talking about a fast CPU in every wall, or a CRTs all over the place. In the image they show a simple B&W LCD input, which would use very little power.
I do wonder about the material cost to produce some of these electronics -- but, honestly, I don't really know what that cost is. My impression is that CRTs are the worst offenders among typical computer parts, but even circuitry is fairly environmentally costly (mostly using large amounts of water to manufacture, and perhaps requiring raw minerals who's mining is environmentally damaging).
A language is for humans to use; it should reflect how humans think. Give the computer the tedious job of normalizing that input, and spare the human's cycles for more important things.
I understand, but disagree, with the basic Perl philosophy. I think Perl succeded more because it filled a niche at the right time -- an interpreted language that allowed quick development. Tcl was too limited, the Lisps were too inaccessible.
But this isn't the place to debate Perl philosophy. I do want to note that Dijkstra wasn't talking about the complexity of the compiler. Not just compilers, but also humans have to normalize the input when they are reading the code. Perl is notoriously bad on this count.
The Fraternal Order of Police has consistently come down on the wrong side of police brutality issues. They fight any civilian oversite, or if oversite exists they keep it from having any real power. They rabidly defend brutal, repeat-offender police, and they have introduced a system of "due process" that makes it difficult to fire a police officer for their actions.
Is the Fraternal Order of Police the same as The Police? No, but it seems like a good approximation.
Are cops who beat people up bad? Yes. Are there reprocusions for their actions? Usually not.
Are cops who watch other cops beat people up bad? Yes. Are there reprocusions for their (non) actions? Never.
I can't remember the last time I heard about the police policing themselves responsibly. I seldom see police really paying for their actions -- not just borderline actions, but truly evil actions. Torture, murder, rape, planting evidence, spewing racism across police bands, framing innocent people, lying in court over and over. In a very few highly publicised cases they have payed, though in just as many highly publicised cases they have not. In the less publicised cases they never do.
The cops have earned their reputation. They continue to earn their reputation day in and day out. It sure as hell isn't the media that makes people hate cops -- they won't touch police brutality with a ten foot pole.
All cops aren't bad. But it's incredibly hard to be a good cop in this system. Because to be a truly good cop, you can't stand by knowing that your coworkers are doing wrong. But if you stand up against them, you will suffer for it. The Fraternal Order of Police won't stand by you then.
Re:Dear Larry: Are you crazy?
on
Ask Larry Wall
·
· Score: 3, Interesting
You're wrong when you say "we're really simplifying" -- you're making things more complex.
I think Scareduck is right here. Backward-compatibility modes will not make Perl, the totality, less complex; quite the contrary. Going forward there will be two significant different syntaxes for regexes, with the potential for great confusion if you don't know which one you are using. It also means two syntaxes to learn, with false cognates that are more likely to confuse than if the syntaxes were radically different.
The old syntaxes for Perl are not going anywhere. By introducing new syntaxes, Larry is making Perl syntax twice as complex. It is already known as a syntactically complex language.
If this quote isn't entirely ontopic for this discussion, it certainly is for Perl as a whole:
"I thought that it was a firm principle of language design -- out of
concern for programming as a human activity -- that in all respects
equivalent programs should have few possibilities for different
representation [...]. Otherwise completely different styles of
programming arise unnecessarily, thereby hampering maintainability,
readability and what have you. This requires from the language
designers the courage to make up their minds!"
-- Edsger W. Dijkstra on Ada
(source)
Not only didn't Larry make up his mind the first time around, but now that the creation has settled he's changing it all over again.
Visit my website at www.leetzor.com!
Wow, that's really useful. Just as useful as:
Call me! My phone number is 523-555-3125!
First, that's silly. Leetzor.com is much easier to remember than 523-555-3125, and you know it.
Second, I didn't say domain names should be a search system. They are an address. Your arbitrary addresses have been used in Brasilia for house addresses, and my understanding is they suck -- the address says nothing about the location, and there is no good way to remember what something's address is. Phone numbers are also arbitrary, and very hard to remember, hence 1-800-CALLATT and the like -- you don't think, "hey, I bet AT&T offers calling service!", you remember the name after its been specifically told to you. And I believe Sprint (or MCI?) even got 1-800-ATTCALL and redirected it to 1-800-COLLECT, just like the problems with DNS. In the early days of phone numbers, even individuals had mnemonic phone numbers; the advantages have long been clear.
Using arbitrary domain names is a step backward. Just because the problem is hard, you're saying we should give up. I think we can do better.
If we made a hundred GTLDs instead of three or ten, then the price of
monopolizing a name for speculation would be 10x to 30x the current
price. At the same time, the value of any one of those names would
drop significantly, since most of them are replaceable by each other.
If the speculators had only bought 90 of the 100 names, a company that
wanted to be "CompanyX.something" could become "CompanyX.okay" or
"CompanyX.oui" -- without paying a dime to the speculators. They'd
lose their entire investment in buying up "CompanyX" names.
That doesn't make sense to me -- sure, you could use CompanyX.okay instead of CompanyX.something, but that's just a way of saying "let's make domains useless and random, then we can't speculate."
.com has been overloaded, obviously. But without clearly-defined alternate TLDs, I don't see how adding more will help. Maybe (though unlikely) after a couple years.com will lose it's canonical identity. But people still won't be able to remember the name of a site. This isn't a question of search engines, but of having a meaningful domain system. If you want meaningless, use IP addresses, or get one domain and create serial numbers below it for every individual site/computer (if you want to be IP-address independent).
Real people, however, want meaningful domain names. If you have a hundred TLDs, many of them will overlap conceptually. Who can remember the difference between.biz and.bus, or.game and.toy? They might remember your carefully chosen second-level domain, but with generic TLDs they won't be able to get to it. Unless you register the name in all related TLDs. But isn't that what we were trying to get away from?
We have been attacked by multi-level marketers and spammers, and those people are damaging the system greatly. But we can't win by trying to beat them at their game -- by diluting the system so greatly that they can't play. That just ruins the game for everyone, and the MLMers and spammers will still be there anyway. I don't like ICANN, but I do think that well-defined, meaningful, sometimes regulated, and non-overlapping TLDs are essential. This makes ICANN all the worse, because something like it is essential, but done the wrong way (with the wrong people influencing it) it will again damage the system.
If US$15 is too much for a person, then internet access is likely too much for the person. Anyone poor enough not be able to own a domain is too poor to do anything with the domain anyway. US$100 is a bit more borderline, but should still be accessible for anyone who can actually afford to use the domain.
Defining "non-profit" seems very difficult to me. 503c? That's pretty difficult to get -- it takes quite a while (generally at least a year, I believe), and there's quite a few formal requirements. Because of that, a lot of new non-profit-like organizations attach themselves to a 503c, who collects money for them and performs other (mostly financial) services. But then one 503c will have to own many domains.
Anyway, 503c is silly to require -- it's US-only, and doesn't cover a significant portion of actual "organizations". Lazylightning.org is not a "valid non-profit organization", it's personal, and those aren't the same things (it also doesn't have any valid connection to the Grateful Dead -- it would be more appropriate for you to use your own name).
If not formally non-profit, what then? Perhaps you could ban for-profit corporations from.org. Corporations obviously could get a 503c designation if they were validly non-profit (or the not-for-profit designation which is slightly different). This might work okay, and a "corporation" is a well-defined international concept.
But it's still difficult to determine what the limit for domain names registered would be. There are innumerable valid reasons for one organization/person to own multiple domains. Where would you draw the line?
Mostly, if we could get rid of blatantly invalid domain registrations (e.g., mispellings that point to those stupid search engines) and domains that are registered but not used (or have "under construction" for two years), then it would probably be a lot better. Of course, keeping aggressive trademark owners from manipulating the system is also important.
This is difficult as long as individuals have access to the system, as the system would continue to be manipulated by multi-level marketing companies, who work "through" individuals for their nefarious (or rather annoying) schemes.
And there's nothing wrong with registering a misspelling, so long as it's a misspelling of a domain you own (which I think is what the original poster is refering to). At a certain point it gets silly, but sometimes it is important (for instance, if you used lazy-lightning.org, you'd probably also want lazylightning.org, as it's hard to remember the difference between the two).
I agree that keyboard shortcuts are great, but browsers aren't very usable strictly from the keyboard. Mostly, there's no (good) way to follow links. So you have to use the mouse, and so mouse shortcuts are worth it. That's how I think of pie menus.
In contrast, pie menus would be silly compared to keyboard shortcuts when using a word processor.
If you really think it's so important to coddle newbies (who are only newbies for the first 6 months of using a computer) [...]
I was actually thinking of anyone who's new to an application. Pie menus are a novel input, and take some getting used to, but that's okay. But I don't think an individual will see an advantage to pie menus until after they've become experienced with an application. There aren't that many applications that we really become familiar with -- as in, use-the-app-for-an-hour-a-day kind of familiar. I think pull-down menus are better for unfamiliar applications, because they are easier to explore.
I think we both agree, though, that familiar applications are used intensly enough that having a deep interface is worth it (deep as in, requires some work to use efficiently).
A number of people here have criticised this, saying that pie menus have been around for a long time and no one uses them, and they are just a plaything. I disagree. But while I think there is significant stagnation in UI inventions, it is not purely because of inertia that pie menus have not caught on.
One of the biggest advantages to pie menus is that you can learn the motions, and perform those actions automatically without visual feedback. This is very hard to achieve with drop-down menus.
However, in a large number of applications this is not particularly useful. I don't think pie menus are very useful when learning the application -- with a menu of items, it is fairly easy to scan through the descriptions. They are listed, top to bottom, and this is how we are used to reading (not top-left-right-bottom). It's also easy to skim a large number of menu items by dragging the mouse through the menubar. The only payoff for pie menus is later when you have memorized the action.
In most applications you won't have a chance to memorize the action. Most menu actions will only be performed very sporatically -- the user might only use the application once a week, or they might use a wide variety of actions which are too large to fit on a pie menu. My (wild) guess is the user has to use the particular action at least two times a day on average to learn the motions ("muscle memory").
One exception might be a word processor or a spreadsheet -- there's lots of repetitive tasks. However, in these situations keyboard shortcuts are superior -- the user is already using the keyboard, and moving from the keyboard to do gestures will not help them.
The other big exception is the browser and games. People have mentioned games already -- they are novel interfaces, and you are already expected to learn a lot of new rules to play any game, adding the pie menu interface isn't a difficult. With the obsessiveness of gaming, and the need to simplify oft-repeated actions, pie menus are a perfect fit.
Then there's browsers: when using a browser, there are a small set of actions that are repeated over and over (back, forward, close, etc). People also use a browser for long periods -- hours each day -- so they have time to learn even fairly complex actions. Lastly, they usually browse with the mouse, not the keyboard. Just like mouse scroll wheels are a useful alternative to the keyboard shortcuts (the arrow and page up/down keys), gestures can be a useful alternative to other keyboard shortcuts (Ctrl-Left, etc).
The other area where pie menus would seem very useful would be visual editing environments -- things like Photoshop or Blender -- where you are working largely with the mouse, and do so for long enough periods that you could build muscle memory for your most often used actions.
Morphic has had speed problems for a long time -- I hear it's faster since I last used Squeak, but I have no idea how much faster. Squeak's strong anti-C bias may be hurting it here, because I imagine there could be some significant optimizations by coding more of the primitive graphical operations in C (or C-translated-from-Smalltalk).
However, Squeak didn't start with the Morphic widgets, and it should still have a "classic" environment. These widgets are much less general, much less fancy and interactive, but way faster. It's quite usable.
Morphic, IMHO, is cool but has very serious problems (lack of documentation and speed being the biggest). But you shouldn't disregard Squeak just because of it -- there's a lot of interesting stuff going on in it. (Probably not very practical for actual deployment of apps, though -- more of an experimentation platform)
Maybe you have better muscle memory than me, but I absolutely have no ability to automatically hit menu entries. If you think you can, then try it out: try to select "reload" from the context menu with your eyes shut. And without practicing -- you can remember any one distance by practicing, maybe any two, but menus are typically longer than two entries.
If you can't do it with your eyes shut, it isn't muscle memory. I have fantastic keyboard muscle memory, but even then it's clearly not distance memory. On a keyboard, I remember the hand positions -- because the base of my hand doesn't move as I touchtype, each key makes my finger curl to a different degree. When hitting keys that require me to move my hands -- function keys, for instance -- I have a great difficulty doing it without looking. After repetition, I can remember a small number of distances -- to the backspace key, for instance -- but it is very limited and requires constant reinforcement.
This all is true of mouse movements as well -- muscle memory for distance just sucks. How often do you make a mistake that you move your mouse in the wrong direction? The only time I've had that problem is with the iMac mice that were easy to hold sideways. How often do you move the mouse the wrong distance? I do that many times each day -- I went to edit this last sentence, and moved my mouse about two pixels below the text box, requiring a correction. Hell, I probably make those mistakes on at least 10% of my mousing -- though I suspect it's closer to 80%, when you consider that almost all mousing involves a large movement to the general area (which is inaccurate), and then a series of smaller corrections until you are within the target area.
Almost every Emacs user I know, also occasionally runs VI, usually for a quickie edit, not wanting to wait for emacs to load.
I can't imagine using vi even for small files -- it's the only editor where there is a sharp learning curve to quit out of the damn thing. Besides learning the incantation to quit, I haven't bothered to learn more vi.
For Emacs-users wanting to do a quick edit, I would highly recommend Zile, which will be very familiar, but loads very fast. I don't code in it, but when I'm editing configuration files and such (as root) it works great.
Of course, Emacs users should use gnuclient when they can (which will open up another window for Emacs, without starting up a second instance of the editor). Also, there's a trick using Tramp to ssh into your own box as root, allowing you to edit configuration files along with normal files, all under one Emacs instance. We can't keep other people from using vi, but armed with the proper tools we can at least carve out a vi-free space for ourselves:)
If the NSA software would compete with MS, then the government has no business releasing it.
Quite the contrary -- if the NSA or any government agency is producing software that, at no extra cost to them, could benefit the public, then it has no business keeping it to themselves.
On your argument, municipalities should not be selling water (at dirt-cheap prices too) when there's private companies selling the same product. Should Danon demand that everyone buy water in bottles, rather than having it subsidized by the state?
The metaphor continues when you realize that the government actually can give water away for very little, and that bottled water companies are manipulative -- selling the same product for a higher price, and introducing innumberable inefficiencies in the process. So it is with SELinux -- MS wants to sell something inferior, inefficient, and overpriced. That's not the free market, it's just another company that wants to drag down the entire nation so it can make a few bucks. I'm sorry, but the advancement of the People of the United States trumps any corporate, profit-motivated interest.
Integrating the language and the OS kills portability, robustness, and security.
I think you need to do more to explain this particular argument. First, what kind of portability? I.e., portability with respect to what? CPU, programming language, programming paradigms, spoken language...? Really, I don't see any portability issue except with respect to programming language.
And why security? There's been a lot of work, and only moderate success, in creating secure computing environments. Java seems to do alright, but its security model also often cripples the program -- and it also introduces an environment that subsumes the OS... in the end, we have what is a sort of OS ontop of a OS in Java (ditto Smalltalk, and now dot-NET).
Robustness... well, I don't know. The cooperative multitasking that Smalltalk used was mostly for performance reasons. I imagine a number of other systems made similar compromises. I don't know to what degree that's a result of the language-OS tie... except that the tie seems to be made most often in situations where the original programmers have great faith in themselves and their mindfulness, which is not necessarily an appropriate faith when the system gets used by others. C also has very serious problems with robustness -- but because that language is so bad, an OS tries to make up for it by placing limits on the process. This only goes so far... sure, you can't ruin someone else's memory space, but you can introduce security holes, suck up unnecessary resources, etc. And when hardware doesn't have safe interfaces (e.g., through X), it's not that difficult to bring parts of the machine down.
And lastly - the simplicity of MySQL is largely an illusion - since without transactions, subselects, views, etc you've simply moved the complexity from the database to the application layer.
A large part of the simplicity of MySQL is not in its implementation but its administration. That's why something like Firebird (AKA InterBase) is not that popular, even though it's a full RDBMS. I feel like the mature development of packaging is not a well-appreciated part of open source projects. MySQL is easy to install, easy to set up, easy to back up, etc. -- and this isn't because it's less featureful, but because it hasn't been managed by professional database managers through its development life.
MS SQL is probably about as easy to set up as MySQL -- MS deserves credit for packaging software for the masses -- but few other commercial offerings seem to come close. In an environment where professionals are born of amateurs (as opposed to specialized training), these shrink-wrapped databases will have a strong advantage. I don't think it's certain that this environment will come to pass (far from certain, really) -- but if it does, then Oracle does have something to worry about. Because then it's not just if MySQL is good enough now, but if it gets better fast enough to grow with the skills and responsibilities of those who have started out with it (again, it hasn't kept up so far, but when it does it will be before it actually matches Oracle feature-for-feature).
What definition of RDBMS are you using? I couldn't find my text book from my college days, and unfortunately I don't know an authoritative definition nor an authoritative location of CS definitions... this was the best I found. If you have a better definition, please post it.
This definition mentions such concepts as tables, relations between those columns, joins, etc. RDBMS is not an elitist term, as far as I can see -- it's a description of a class of databases. Other kinds of database exist: bdb (file-based hash), ZODB (an object store), hierarchical databases, and others. MySQL isn't one of those -- it is a relational database. It has tables, it has joins (even if integrity isn't ensured), it has a query language (that is not imperative)... it isn't a terribly featureful example, it does not pass the ACID test, but it is a relational database. A lot of the features given aren't even part of the original concept of an RDBMS (stored procedures in particular).
This database pretentiousness is kind of tiring. Whenever anyone brings up MySQL in any way, someone goes, "without subselects it's not even worthy of the term RDBMS" or somesuch.
Well, sorry, but it is worthy. It's not a "full" database like you'd like for your work, but it's more than enough for a huge number of problems. It's too bad it doesn't work for you, or it doesn't work for one particular domain of problems you deal with. Just because it doesn't work for you doesn't mean it doesn't work well for lots of other people. There are a ton of small database projects (often websites) where MySQL not only is sufficient, but is superior to Oracle. And websites aren't the only potential domain -- Oracle, for instance, would be absurd to embed in an application (and there are a ton of crappy applications based around MS's JET database engine, and MySQL kicks JET's ass).
And yes, MySQL is a competitor. It's not a drop-in replacement for every Oracle installation, but there's a lot of new projects where MySQL is used where Oracle or another database may have been necessary otherwise. It's a pretty decent structured store for read-only data.
This is quite common when people suggest some free software may be a threat to some proprietary software, and then twenty people say, "X won't be a real competitor to Office (or Solaris, or Photoshop, etc) until it has feature Y", where Y is whatever feature they use. As though the world (or, rather, the marketplace) revolves solely around them, or as if the free software developers have a duty to seek that person's approval.
Slashdot Mirror
Bogomail potentially captures more relevent words than as described by Graham -- IP addresses, email addresses, and other text that should be considered atomic are recorded atomically. I think even more could be done with this -- but I worry that bogofilter is going to create too large a database, as it even seems to be keeping track of words like "$20".
As an optimization, I could imagine you could double-register some words, mostly those in headers. So the word "mother" in a subject line might register both "mother" and "subject:mother". Perhaps IP addresses could be recorded with all their classes (e.g., "200.69.228.105" would be recorded as "200.69.228.105", "200.69.228", "200.69" and "200" -- maybe prefixing some text to the last three, so that "200" the number is distinguishabe from "200" the class-A address)
Ultimately, a well trained spam database could be trimmed and distributed, but bogofilter does not yet include such a database. Graham's concern about distribution and trust are, IMHO, not entirely necessary -- a well-trained database can be created by only a handful of people (who receive lots of spam), and even if non-spam must be classified on an individual basis, spam is not tailored to any individual (nearly by definition). I don't think this has as great a risk of censorship as blocking lists.
I would be interested to see an improvement in the client end of bogofilter (or similar software). Right now I'm using procmail, and forwarding miscategorizations back to myself with a changed subject line (which procmail catches and feeds to bogomail). With just a little work, this could be used to create filters besides spam, where I train bogofilter to filter based on other criteria. (Well, I can do this right now, but it would take only a little work to make this accessible even to computer novices)
I think what Reiser is talking about could be truly novel -- I'm sure someone has thought of it before, but I don't know that anyone's made it happen in a real OS. (Though I wouldn't be surprised to see it in an experimental OS)
You can understand most of Scheme, but after working with it for a long time, I still don't really understand call/cc.
Other people might feel that Forth was a better language -- having just enough abstraction to allow some modularity, but only barely. Nearly all virtual machines look like Forth machines... I suppose that implies that computer scientists disagree with electrical engineers as to how a machine should act.
All the blame should go to the batteries. None of it need go to the motors.
IMHO, the only public transit system that could be a viable alternative to cars in the US is Personal Rapid Transit.
I do wonder about the material cost to produce some of these electronics -- but, honestly, I don't really know what that cost is. My impression is that CRTs are the worst offenders among typical computer parts, but even circuitry is fairly environmentally costly (mostly using large amounts of water to manufacture, and perhaps requiring raw minerals who's mining is environmentally damaging).
But this isn't the place to debate Perl philosophy. I do want to note that Dijkstra wasn't talking about the complexity of the compiler. Not just compilers, but also humans have to normalize the input when they are reading the code. Perl is notoriously bad on this count.
Are cops who beat people up bad? Yes. Are there reprocusions for their actions? Usually not. Are cops who watch other cops beat people up bad? Yes. Are there reprocusions for their (non) actions? Never.
I can't remember the last time I heard about the police policing themselves responsibly. I seldom see police really paying for their actions -- not just borderline actions, but truly evil actions. Torture, murder, rape, planting evidence, spewing racism across police bands, framing innocent people, lying in court over and over. In a very few highly publicised cases they have payed, though in just as many highly publicised cases they have not. In the less publicised cases they never do.
The cops have earned their reputation. They continue to earn their reputation day in and day out. It sure as hell isn't the media that makes people hate cops -- they won't touch police brutality with a ten foot pole.
All cops aren't bad. But it's incredibly hard to be a good cop in this system. Because to be a truly good cop, you can't stand by knowing that your coworkers are doing wrong. But if you stand up against them, you will suffer for it. The Fraternal Order of Police won't stand by you then.
The old syntaxes for Perl are not going anywhere. By introducing new syntaxes, Larry is making Perl syntax twice as complex. It is already known as a syntactically complex language.
If this quote isn't entirely ontopic for this discussion, it certainly is for Perl as a whole:
Not only didn't Larry make up his mind the first time around, but now that the creation has settled he's changing it all over again.Second, I didn't say domain names should be a search system. They are an address. Your arbitrary addresses have been used in Brasilia for house addresses, and my understanding is they suck -- the address says nothing about the location, and there is no good way to remember what something's address is. Phone numbers are also arbitrary, and very hard to remember, hence 1-800-CALLATT and the like -- you don't think, "hey, I bet AT&T offers calling service!", you remember the name after its been specifically told to you. And I believe Sprint (or MCI?) even got 1-800-ATTCALL and redirected it to 1-800-COLLECT, just like the problems with DNS. In the early days of phone numbers, even individuals had mnemonic phone numbers; the advantages have long been clear.
Using arbitrary domain names is a step backward. Just because the problem is hard, you're saying we should give up. I think we can do better.
Real people, however, want meaningful domain names. If you have a hundred TLDs, many of them will overlap conceptually. Who can remember the difference between .biz and .bus, or .game and .toy? They might remember your carefully chosen second-level domain, but with generic TLDs they won't be able to get to it. Unless you register the name in all related TLDs. But isn't that what we were trying to get away from?
We have been attacked by multi-level marketers and spammers, and those people are damaging the system greatly. But we can't win by trying to beat them at their game -- by diluting the system so greatly that they can't play. That just ruins the game for everyone, and the MLMers and spammers will still be there anyway. I don't like ICANN, but I do think that well-defined, meaningful, sometimes regulated, and non-overlapping TLDs are essential. This makes ICANN all the worse, because something like it is essential, but done the wrong way (with the wrong people influencing it) it will again damage the system.
If US$15 is too much for a person, then internet access is likely too much for the person. Anyone poor enough not be able to own a domain is too poor to do anything with the domain anyway. US$100 is a bit more borderline, but should still be accessible for anyone who can actually afford to use the domain.
Anyway, 503c is silly to require -- it's US-only, and doesn't cover a significant portion of actual "organizations". Lazylightning.org is not a "valid non-profit organization", it's personal, and those aren't the same things (it also doesn't have any valid connection to the Grateful Dead -- it would be more appropriate for you to use your own name).
If not formally non-profit, what then? Perhaps you could ban for-profit corporations from .org. Corporations obviously could get a 503c designation if they were validly non-profit (or the not-for-profit designation which is slightly different). This might work okay, and a "corporation" is a well-defined international concept.
But it's still difficult to determine what the limit for domain names registered would be. There are innumerable valid reasons for one organization/person to own multiple domains. Where would you draw the line?
Mostly, if we could get rid of blatantly invalid domain registrations (e.g., mispellings that point to those stupid search engines) and domains that are registered but not used (or have "under construction" for two years), then it would probably be a lot better. Of course, keeping aggressive trademark owners from manipulating the system is also important.
This is difficult as long as individuals have access to the system, as the system would continue to be manipulated by multi-level marketing companies, who work "through" individuals for their nefarious (or rather annoying) schemes.
And there's nothing wrong with registering a misspelling, so long as it's a misspelling of a domain you own (which I think is what the original poster is refering to). At a certain point it gets silly, but sometimes it is important (for instance, if you used lazy-lightning.org, you'd probably also want lazylightning.org, as it's hard to remember the difference between the two).
In contrast, pie menus would be silly compared to keyboard shortcuts when using a word processor.
I think we both agree, though, that familiar applications are used intensly enough that having a deep interface is worth it (deep as in, requires some work to use efficiently).
One of the biggest advantages to pie menus is that you can learn the motions, and perform those actions automatically without visual feedback. This is very hard to achieve with drop-down menus.
However, in a large number of applications this is not particularly useful. I don't think pie menus are very useful when learning the application -- with a menu of items, it is fairly easy to scan through the descriptions. They are listed, top to bottom, and this is how we are used to reading (not top-left-right-bottom). It's also easy to skim a large number of menu items by dragging the mouse through the menubar. The only payoff for pie menus is later when you have memorized the action.
In most applications you won't have a chance to memorize the action. Most menu actions will only be performed very sporatically -- the user might only use the application once a week, or they might use a wide variety of actions which are too large to fit on a pie menu. My (wild) guess is the user has to use the particular action at least two times a day on average to learn the motions ("muscle memory").
One exception might be a word processor or a spreadsheet -- there's lots of repetitive tasks. However, in these situations keyboard shortcuts are superior -- the user is already using the keyboard, and moving from the keyboard to do gestures will not help them.
The other big exception is the browser and games. People have mentioned games already -- they are novel interfaces, and you are already expected to learn a lot of new rules to play any game, adding the pie menu interface isn't a difficult. With the obsessiveness of gaming, and the need to simplify oft-repeated actions, pie menus are a perfect fit.
Then there's browsers: when using a browser, there are a small set of actions that are repeated over and over (back, forward, close, etc). People also use a browser for long periods -- hours each day -- so they have time to learn even fairly complex actions. Lastly, they usually browse with the mouse, not the keyboard. Just like mouse scroll wheels are a useful alternative to the keyboard shortcuts (the arrow and page up/down keys), gestures can be a useful alternative to other keyboard shortcuts (Ctrl-Left, etc).
The other area where pie menus would seem very useful would be visual editing environments -- things like Photoshop or Blender -- where you are working largely with the mouse, and do so for long enough periods that you could build muscle memory for your most often used actions.
However, Squeak didn't start with the Morphic widgets, and it should still have a "classic" environment. These widgets are much less general, much less fancy and interactive, but way faster. It's quite usable.
Morphic, IMHO, is cool but has very serious problems (lack of documentation and speed being the biggest). But you shouldn't disregard Squeak just because of it -- there's a lot of interesting stuff going on in it. (Probably not very practical for actual deployment of apps, though -- more of an experimentation platform)
If you can't do it with your eyes shut, it isn't muscle memory. I have fantastic keyboard muscle memory, but even then it's clearly not distance memory. On a keyboard, I remember the hand positions -- because the base of my hand doesn't move as I touchtype, each key makes my finger curl to a different degree. When hitting keys that require me to move my hands -- function keys, for instance -- I have a great difficulty doing it without looking. After repetition, I can remember a small number of distances -- to the backspace key, for instance -- but it is very limited and requires constant reinforcement.
This all is true of mouse movements as well -- muscle memory for distance just sucks. How often do you make a mistake that you move your mouse in the wrong direction? The only time I've had that problem is with the iMac mice that were easy to hold sideways. How often do you move the mouse the wrong distance? I do that many times each day -- I went to edit this last sentence, and moved my mouse about two pixels below the text box, requiring a correction. Hell, I probably make those mistakes on at least 10% of my mousing -- though I suspect it's closer to 80%, when you consider that almost all mousing involves a large movement to the general area (which is inaccurate), and then a series of smaller corrections until you are within the target area.
For Emacs-users wanting to do a quick edit, I would highly recommend Zile, which will be very familiar, but loads very fast. I don't code in it, but when I'm editing configuration files and such (as root) it works great.
Of course, Emacs users should use gnuclient when they can (which will open up another window for Emacs, without starting up a second instance of the editor). Also, there's a trick using Tramp to ssh into your own box as root, allowing you to edit configuration files along with normal files, all under one Emacs instance. We can't keep other people from using vi, but armed with the proper tools we can at least carve out a vi-free space for ourselves :)
On your argument, municipalities should not be selling water (at dirt-cheap prices too) when there's private companies selling the same product. Should Danon demand that everyone buy water in bottles, rather than having it subsidized by the state?
The metaphor continues when you realize that the government actually can give water away for very little, and that bottled water companies are manipulative -- selling the same product for a higher price, and introducing innumberable inefficiencies in the process. So it is with SELinux -- MS wants to sell something inferior, inefficient, and overpriced. That's not the free market, it's just another company that wants to drag down the entire nation so it can make a few bucks. I'm sorry, but the advancement of the People of the United States trumps any corporate, profit-motivated interest.
And why security? There's been a lot of work, and only moderate success, in creating secure computing environments. Java seems to do alright, but its security model also often cripples the program -- and it also introduces an environment that subsumes the OS... in the end, we have what is a sort of OS ontop of a OS in Java (ditto Smalltalk, and now dot-NET).
Robustness... well, I don't know. The cooperative multitasking that Smalltalk used was mostly for performance reasons. I imagine a number of other systems made similar compromises. I don't know to what degree that's a result of the language-OS tie... except that the tie seems to be made most often in situations where the original programmers have great faith in themselves and their mindfulness, which is not necessarily an appropriate faith when the system gets used by others. C also has very serious problems with robustness -- but because that language is so bad, an OS tries to make up for it by placing limits on the process. This only goes so far... sure, you can't ruin someone else's memory space, but you can introduce security holes, suck up unnecessary resources, etc. And when hardware doesn't have safe interfaces (e.g., through X), it's not that difficult to bring parts of the machine down.
MS SQL is probably about as easy to set up as MySQL -- MS deserves credit for packaging software for the masses -- but few other commercial offerings seem to come close. In an environment where professionals are born of amateurs (as opposed to specialized training), these shrink-wrapped databases will have a strong advantage. I don't think it's certain that this environment will come to pass (far from certain, really) -- but if it does, then Oracle does have something to worry about. Because then it's not just if MySQL is good enough now, but if it gets better fast enough to grow with the skills and responsibilities of those who have started out with it (again, it hasn't kept up so far, but when it does it will be before it actually matches Oracle feature-for-feature).
This definition mentions such concepts as tables, relations between those columns, joins, etc. RDBMS is not an elitist term, as far as I can see -- it's a description of a class of databases. Other kinds of database exist: bdb (file-based hash), ZODB (an object store), hierarchical databases, and others. MySQL isn't one of those -- it is a relational database. It has tables, it has joins (even if integrity isn't ensured), it has a query language (that is not imperative)... it isn't a terribly featureful example, it does not pass the ACID test, but it is a relational database. A lot of the features given aren't even part of the original concept of an RDBMS (stored procedures in particular).
If MySQL is not relational, then what is it?
Well, sorry, but it is worthy. It's not a "full" database like you'd like for your work, but it's more than enough for a huge number of problems. It's too bad it doesn't work for you, or it doesn't work for one particular domain of problems you deal with. Just because it doesn't work for you doesn't mean it doesn't work well for lots of other people. There are a ton of small database projects (often websites) where MySQL not only is sufficient, but is superior to Oracle. And websites aren't the only potential domain -- Oracle, for instance, would be absurd to embed in an application (and there are a ton of crappy applications based around MS's JET database engine, and MySQL kicks JET's ass).
And yes, MySQL is a competitor. It's not a drop-in replacement for every Oracle installation, but there's a lot of new projects where MySQL is used where Oracle or another database may have been necessary otherwise. It's a pretty decent structured store for read-only data.
This is quite common when people suggest some free software may be a threat to some proprietary software, and then twenty people say, "X won't be a real competitor to Office (or Solaris, or Photoshop, etc) until it has feature Y", where Y is whatever feature they use. As though the world (or, rather, the marketplace) revolves solely around them, or as if the free software developers have a duty to seek that person's approval.