A lot of people are mentioning the "numbers game."
This may explain why when I call 411 on my cell phone, most of the time the reps hang up (redirect to the phone number) after I tell them "Yes, that's the one." As I'm opening my mouth to say "Can I have the exact address?", I hear the automatic "We are now placing a call to..."
If MADD had their way, they'd have a detector that if you touched a bottle of alcohol in the last two hours, you'd get a ticket for attempting to start your car. You think I'm kidding, but with an ignition interlock and the ever-falling BAC levels, it may just happen. (Do everyone a favor and read why MADD is mad.).
BTW, unlike MADD or a rambling lunatic, I'm going to back up every claim with a link.
MADD (and NHTSA) grossly overexaggerate their claims of "drunk driving accidents," which are really alcohol-related accidents (a misleading statistic used by NHTSA). Did you know that if you, while 100% sober, hit a drunk pedestrian, it counts as an alcohol-related accident? Or did you know that if you get in an accident and EVERYONE is sober (driver, pedestrian, passengers), you can still be counted as alcohol-related due to the statistical correction that NHTSA uses, since only 63% of drivers are tested for their BAC level!
MADD claims that 0.08 BAC reduction saves lives, yet a study by NHTSA found no proof of such reduction after North Carolina enacted the lower BAC limit: "There appears to have been little clear effect of the lower BAC limit in North Carolina. Survey data
indicate that the general public believes the new law was well-publicized. Although awareness of the new
lower limit was not particularly high nearly 18 months after the law took effect, frequent drinkers did
evidence a substantial degree of awareness that the law had changed and about what the new BAC limit
was. As is typical in North Carolina, enforcement of the lower limit was vigorous and strict."
MADD wants to lower the BAC limit lower and lower, to 0.05. It claims victory over the 0.08 law over the previous 0.10 standard. However, it has been found that "the
relative risk [of being in a traffic accident while using a cell-phone] is similar to the
hazard associated with driving with a blood alcohol level at the legal limit." The legal limit in that paper was 0.10 BAC. Another interesting note is that "These data also call into question driving regulations that prohibit handheld
cell-phones and permit hands-free cell-phones, because no significant differences in
the impairments caused by these two cellular devices were found.", but that's another topic of conversation.
Point is, why do they want to keep lowering the BAC when it has been shown that the vast majority of drunk driving accidents occurs with drivers with over 0.10 BAC, and that below that, it's as risky as using a cell phone? Why is MADD targeting low-BAC-level drivers, such as 0.08 (and as they hope 0.05), with huge fines, property confiscation, loss of driver license, and obscene insurance surcharges? MADD wants to bully states into the 0.08 BAC law by passing legislation that threatens their funding.
Furthermore, when NHTSA's accident data was loaded in a database and independent statistics were ran on it, the massive exaggerations were exposed. Quote from the previous link: "Through the use of this tool we were able to discover that across the entire country NHTSA nearly doubles the number of instances of drunk drivers. And this is prior to them implementing their "Multiple Imputation" methodology w
I wicked agree... that GoogleWatch site is full of crap. Same stuff applies to Yahoo, IMDB, AltaVista, any other search site.
The fact is that your search queries are logged no matter what search engine you are using. If you follow a link from one website to another, the other web site can log where you came from.
Airport in France. American and German leaders meet. As the French come to the American airplane, George W Bush comes out, sniffs everyone from the French delegation, picks up some dirt off the ground, puts it in his pocket and returns to the airplane.
A few minutes later an American scientist apologizes: "We messed up: instead of the Presidential visit program, we loaded up the Mars rover one".
Question 58: Can I develop my applications on Windows, and deploy on a supported Mono platform (like Linux)?
Yes, you can.
As of today, Mono is not 100% finished, so it is sometimes useful to compile the code with Mono, to find out if your application depends on unimplemented functionality.
So in short, yes, you can compile C# and C++ to bytecode under Windows and run it under Linux.
Although what you said about CLA (being able to call other languages' functions) is correct.
I should preface this that at work I use vi because I have to, and I never suffered through learning all the emacs keystrokes to make using emacs efficient.
I have tried each and every release of Eclipse and found it to be a terrible IDE. It's so unintutive that I could almost believe that Sun made their Solaris developers work on it in secret just to piss of Sun.
What are you talking about? Could you please substantiate your claim with specific examples?
Coming from old DOS Borland interfaces (e.g. for Turbo Pascal), from Visual Studio interfaces, from a bunch of others, I find Eclipse to be rather well-done, relatively non-frustrating (unlike *ahem* vi and emacs). Eclipse really is very good. The code assist features are a fanstastic time saver.
What's with SWT? It's horrible to code with. It has no really control over look and feel. You have to dispose of everything explicitly (al la C++) which completely goes against Javas garbage collection paradigm.
I right an app in SWT it looks one way on Windows and another way on Gnome (usually a complete mess on one).
Have you considered that maybe you were doing something wrong? What about Eclipse-- it looks pretty much the same (and correct) to me in both GNOME and Windows.
If you want complete control over look and feel, use Swing. It's actually a *benefit* that the look and feel is specific ot a platform.
Don't get me wrong I think Forte and Sun One are pretty awful too. The only sensible choice in the IDE market right now is Intellij (no don't work for them). However this IDE is not open or free (unfortunately).
Can you provide arguments as to why Intellij is better? Or why it's the only sensible choice?
Personally I don't think Sun or IBM are particularly good at writing software and should stick to their Hardware and Consulting (IBM) core competancies.
(pretending to be like you)
Personally, I don't think you're very good at writing software, or making substantiated arguments, so you should stick to reading Slashdot.
But really, IBM has some great software out (the alphaworks site, for example), and Sun didn't make the worst language ever either.
Having served as a "tech support boy" to my family and their friends and their friends' friends back in the day, and having been around different environments with different kinds of people using computers, I have witnessed many a bright person do things that to us, educated computer geeks, would seem either silly, stupid or overly complicated.
So you're going to tell me that an estemeed professor, who has written many papers (or an executive of a successful non-tech company), who has trouble using what we consider basic computer programs... you're going to tell me that he's an idiot and is only qualified to operate an Etcha-Sketch?
You're full of it. Write me a physics paper.
Everyone on Slashdot owes it to themselves to go out and read "Inmates are Running the Asylum" by Alan Cooper (I read mine in a local library). You will be enlightened to no end.
Actually, there's a story behind Zarro Boogs. It is a Mozilla.org (or probably Netscape) term "yeah, we think there are no bugs, but we won't say it so that you don't hold us to it." For example, a milestone reaches "zarro boogs".
NMS Communciations provides Linux drivers and support for their boards (as well as Solaris and Windows).
Re:Some Trillian users express usability concerns
on
Gaim For Windows
·
· Score: 1
Electrical engineers (working on radios) don't design the radios: they design the electronics. An industrial designer designs the radio. Both electrical engineer and industrial designer are quite apt at their job and come together to design software.
Software engineers typically design their software's interfaces, as well as the software's internals. There are usually no user interaction designers involved. That's a problem and what you described about gnucleus is just one example. The software engineer, I bet, does his job quite well, but he just doesn't have the knowledge and experience to develop sensible interfaces.
On another thought, I do remember that one radio I had... I swear an engineer designed it.
Some Trillian users express usability concerns
on
Gaim For Windows
·
· Score: 5, Insightful
Everything is plugin...so nothing but AIM/ICQ out of the box.
I was dropped AT LEAST 5 TIMES in 5 minutes
No copy/paste in chat windows (CTRL=C brings up "Colors")
No right-clicks.
No SecureIM.
Can't click to follow links.
COMPLETELY NON-Intuitive interface
So I don't agree with the "no plugins" argument (just go and download the darn things), but the rest are serious problems.
However, it's alpha! Why treat an alpha release like the final product? So, another poster said:
I did make certain to be distinct in saying WinGAIM and not GAIM. I've not used GAIM and from what I've heard and read, it's kick-ass.
I know *for a fact* that the point in releasing their "alpha" 3 days after the Trillian release was to steal thunder. I also know that seanegan is a frequent guest in one of the Trillian channels, where he openly recruits people to try his software.
Since there is plenty of "Trillian-bashing" going on in Trillian forums, I figured I'd point out that if anyone thinks WinGAIM is a viable alternative, they'll be extremely disappointed.
And I know....it's alpha. But if you're gonna run with the big dogs, you've got to be able to piss in the tall grass.
So any Windows Trillian or AOL AIM users who have tried WinGAIM and have experiences to post?
We use Perforce as well, and I love it. After using Perforce for months now, I can't go back to CVS. Branching, labeling features all make sense.
Creating a branch is very much like copying all the source to another directory (e.g. you had all your source in mysoft directory, which is your trunk.. when you branch, you copy that to mysoft2 directory and now you have a branch.. best of all, every new branch takes up a miniscule amount of disk space, storing only the files you actually change). And then Perforce supplies you with powerful integration tools to let you synch changes across branches.
It has some flaws, like no version control on client, branch and label specs, so if somebody messes up the definition of a branch, you can't step back to the last version, but otherwise it's an excellent source code management (or whatever the right term is) system.
Actually, those MP3s are not recorded with real instruments (I have the CD). All sounds there are just good quality samples of instruments (conforming to General MIDI standard). To be honest, I think that it's possible to do a quite better job of rerecording these tracks even with samples, but it wouldn't preserve that "old skool" Doom sound.
BTW, Bobby Prince is the composer of all of Doom's music, hence him recording all these songs (as opposed to just being a guy that happened to record them to CD).
But yeah, the CD is awesome and I'm glad that I own a copy:)
And finally, a while ago I made a little remix of Doom's E1M1 soundtrack (3.08MB).
I hear your argument a great deal. I used to think the same thing, but I've changed my opinion of the last couple of years.
For once, the car analogy is moot. Not knowing how to drive a car can quite possibly hurt and kill people. Computers, on the other hand, aside from very limited appliations, are not as fatal.
If cars were not as deadly as they are, people would learn how to drive them the same way they learn Word.
"Computer literacy" is the excuse of computer industry for difficult to use software. It's great for companies to say "the user needs some training" and then ease their development effort by not having to worry about improving usability.
Users should not have to be "computer literate" to get e-mail. Or browse web pages. Or write documents. Or use an accounting program.
Why must every computer user these days know the difference between RAM and hard drive? And everyone must, because every program forces the concept of "unsaved" documents upon users. Have you ever, in real life, had an "unsaved" letter or a journal? When you take a journal off the shelf to write something in, do you make an "unsaved" copy to work on and leave the original on the shelf or do you just take the damn journal off? And does your shelf ask you whether you really want to save your journal when you put it back? No! So why do computers do that?
There are many people out there who have accomplished a lot in their lives, who have respectable jobs and are considered to be great in their field of work. Their kids look up to them and call them smart. But if they have trouble using a computer, and they don't have the time to become accustomed to all the quirks and stupidity that computers inflict on us daily, they will fall behind technologically. They will be considered by "techies" as backward and they will be on the "computer illiterate" end of the digital divide.
And that should not be the case. Computer industry (and that includes both commercial and open-source software) are in denial about the poor usability of their products. When they see people struggling with their software, they label them as as computer illiterate and make fun of them. That's quite a bit like sexism and racism: these folks are being "red lined" and left out behind the red line of "computer literacy."
What necessary is for people that design interactive interfaces to learn proper interaction design. If at least half the programmers out in the world who deal with user interfaces were "interaction literate" (and note the emphasis on interaction and not interface), the world's computers would be much less frustrating to use.
And programmers that deal with user interfaces don't have a good excuse to not be decently versed in interaction design: it's their job.
Finally, a comment about learning. I think that learning is core to all computer use. However, too many interfaces these days impede learning or force much more to be learned than necessary. If one tries to avoid learning, if one builds interfaces solely around concepts that people are familiar with in the "real world" (that is, metaphors), one will fail badly.
Users of computer software never stay newbies--they either learn and become intermediate users or drop off the radar.
Consider the mouse. It's in no way an intuitive device. If you never saw a computer, how the hell in the world would you figure out what to do with this object? How could you possibly figure out by looking at the mouse that it moves the cursor on the screen? You may do some really silly things with the mouse, such as lifting it and moving your hand under it to generate cursor movement.
But as soon as you put the mouse down and move it on the screen, you will see the cursor moving. You will learn how to use the mouse in seconds.
Point is, if learning how to use Kazaa was nearly as easy as learning how to use the mouse, people would use it much more, they would be much more loyal to it, and more people would use it. And things like those described in this article could potentially be avoided.
I may have veered off course a few times in this post--sorry about that. All information presented here is my opinion and not necessarily a statement of fact.
Actually, it's CGA first, EGA, then MCGA and VGA. MCGA was very much like VGA (the most important aspect was 256 colors at 320x200), except it didn't support 16 colors at 640x480, only 2.
Ahh! I just realized it!:o( Sorry, dudle, I take back what I said about you. I feel prey to the same 'skim over, heat up and reply' basic instinct... D'oh! The embarrassment (there goes my credibility, heh...)
I wouldn't call it the Push craze, because that one just sorta fell on everyone, suddenly there's a story about it in every magazine (wasn't that fun reading?)
.NET is actually a technology that matured to the point where it is now thru a whole bunch of previous experiments, technologies. It started with the Windows OLE, moved on to COM, COM+, DCOM.
There are non-Microsoft technologies, quite a long time in development, that address some of the important issues address by.NET. For example, if you consider the language-independent object-oriented interfacing, XPCOM, Mozilla's cross-platform component mechansim, is a working technology, and so is CORBA, successfully used by such complex projects as Berlin Consortium. The platform-independent binaries is something Java brought into the light (and boy was there hype at the time), and although not as successfully as expected, it did not fail. However, all of the existing technologies lack one of the big components. XPCOM and CORBA do not provide platform-independence bytecode business, while Java doesn't provide language-independent object communication.
.NET unites a lot of these things together. Do not look at Microsoft.NET--ignore the marketing, the Passport crap, look at the programming tool, technology that is.NET. So.NET is far from vaporware (would you like to see Visual Studio.NET beta?)
But back to your point..NET technology (in the general sense) IS a reason to be excited. I honestly want Ximian to drop everything they do and work day and night on Mono, because it will be so damn useful.
So, Ximian, please spend less time making desktops for one operating system and more time changing face of non-Microsoft-bound projects.
You are a good example of the lack of understanding of what.NET entails. While it is true (and, by the way, publicly stated in the Mono FAQ) that.NET has a shitload of marketing and irrelevant tools associated with it, it really IS innovative.
I know it is hard to comprehend that Microsoft can come up with something innovative, due to the anti-Microsoft mindset of the hoard of Slashdotters, but dig it thru your head. Re-read your post: your whole post is based on the point that.NET is not innovative and that it is a Bad Thing. That point is nothing but dogmatic. It's like childishly crying "This and that sucks!" It's like a convinced Christian telling you that God exists. You try to argue with him about his religion and come to this one point where you may have some REASON in, but, he sticks the dogmatic argument 'God exists' and that's all.
Such is your post. You start off by saying keep an open mind. Fine, and you do admit that "With an open mind you realize that vi and Emacs don't come even close to a fully integrated development environment." Now, in the next friggin paragraph, where.NET is described as having superior dev tools, you ask "What if... I don't know... do you think... is it really... True?" So you just friggin said it's true and now you question yourself.
Basically, face it..NET is a mostly a good thing because of the TECHNOLOGY advancements. The bad thing about.NET is the marketing that Microsoft puts behind it, but that's to be expected. However, describing a technology's benefits is not the kind of blatant marketing that you describe. If I told you that C++ permitted me to write applications in a much more reusable fashion than C, would you tell me in my face that I'm blatantly marketing C++ and that my argument should be discounted?
And the signal that your post is garbage is when you say "I was waiting for someone like you. You give me the opportunity to make my point." What prevents you from making the point, in this post-anywhere, public forum Slashdot? No, the real deal is that you found somebody you can group with and together bash something and otherwise exhibit single-mind group behavior. Just like the blind anti-MS bashing.
Instead of calling a developer much more highly experienced than you a troll, you should read and not skim the articles for possible bitching points. In fact, if anything, your post is on the verge of a flamebait, as you miss both of Miguel's points.</bitchsession>
The IDE issue. Have you developed large software in Linux and using recent Visual Studio? Sure, you can use vi and man, but you do not get things accomplished as quickly or as conveniently. vi has a significant learning curve, whereas Visual Studio IDE is sit down and start typing, and man is not as quick and convenient in retrieval and cross-referencing of the information. Compare putting cursor over the API call you just typed, pressing 'F1' (or is it Ctrl+F1? some keystroke, anyway) in Visual Studio IDE and getting a documentation page, then scrolling down, clicking on a related function and getting the help for it. Think of doing the same function with vi and man. Not nearly as convenient. And does man have cross-referenced, searcahble and indexed tutorials, guides, overviews, references to obscure APIs or APIs that may not be installed on the system? Point is, developing with Visual Studio is just damn convenient, and there are very few Linux tools in development that begin to approach the quality of the Visual Studio IDE. Take it from someone who coded both on Windows, Tru64 (Digital Unix back then), Solaris and Linux.
The DLL issue. This is where you missed the point so far it's not even funny. You are talking about versioning problems (old libraries and such). Now, tell me, if Miguel makes such a big deal out of versioning problems, why isn't it even mentioned on the Mono FAQ page or the issue touched/discussed at any kind of length anywhere? I bet the answer's gonna strike you like a heart attack strikes Dick Cheney: Miguel isn't talking about versioning. There is NO DLL hell (believe me, the versioning problems are not near the hell Miguel has in mind) when you are developing libraries using a statically-typed, procedural language like C. That's because the.so and.dll dynamic library mechanisms are designed to provide procedural APIs (i.e. APIs consisiting of statically-typed functions) and they do it well.
However, if you have ever tried to use object-oriented languages such as C++ with either of the DLL mechanisms (they are for all practical purposes the same) and tried to either provide an object-oriented API or use an object-oriented API, you will learn what the DLL hell means. It means that there is no elegant, straightforward solution to having object-oriented APIs with the DLL mechanisms, everything is a kludge, a hack. And the widely-used hack of exposing the object-oriented API thru a few access C methods (and lotsa casting), means that the client of the library must use the same ABI. And what does that mean? That means constrained to the same programming language, the same compiler (compilers often have different ABIs), and even to certain versions of the same compiler if the ABIs change from version to version. So the DLL hell is when you see a gcc-2.95-built C++ library that you'd love to use in your Delphi app, but you can't. You can't use the Solaris C++ compiler with that library. You can't even use gcc version 3.0 with that library, unless you force it to use the older ABI. (I may be wrong as to exactly which versions of gcc have the differing ABIs, but the point stands.)
I'll give you a real life example. There is a fabulous, free Windows app called Buzz. The plug-ins for that application must all be written in C++ and compiled with Visual C++. In other words, poor, yet talented developers (and in smaller European countries there are plenty) who can't afford Visual C++ 5.0 or 6.0, can't use their existing Delphi or Borland C++ compiler or the win32 port of gcc compiler. Intel C++ compiler? Fogghetaboutit. Raw talent can't contribute--just because the object-oriented-API-enabling DLL hack forces that to be the case.
You don't feel nearly as much heat in the Linux environment because nearly damn everything is built with the same compiler, using close versions (and using C). But you go to some Unix OS machine where the OS and a lot of the libraries are built using the vendor's provided compiler and you taste the hell. You try using an object-oriented Pascal compiler (FreePascal) with a C++ library and you're shit out of luck. Have Python use that C++ library? Can't do directly, gotta write messy translation layers. Same goes for almost any scripting language. Should I keep going with the examples or do you get the point?
Now compare that to Mono. Mono will let you write an OO API library in C++, and use it from something like Python like a normal object, with very little syntactical moronisms.
<bitchsession>So don't label Miguel as a Microsoft cheerleader in hopes of getting the Slashdot crowd moderating your inattentive butt up. And take that 'must consider only one view, must stick to one view' way of writing "eloquent" speeches and high school essays and stick it up where the sun don't shine. Because the world is gray and while Miguel may not subscribe to your views, labeling a developer that contributes so fucking much to the Linux community as a puppet of the Microsoft marketing machine is purely ignorant and ungrateful. In fact, as an aspiring software engineer, it hurts me that you dare use words "rational software engineer" with such an ignorant, non-software engineer viewpoint, as any rational, experienced software engineer that practices object oriented programming will tell you that anything that promotes reuse, avoids having to write a ton of extra code and avoids the above-described real DLL hell, is going to look at this free, open-source initiative (Mono) and say "Thank god, I was waiting for this." You do not nearly realize the kind of freedom and the kind of time savings that Mono will yield in medium and large software projects, something that was previously avaialble only on the Windows platform and for a shitload o' money (Windows + all the dev tools).</bitchsession>
Slashdot Mirror
How does this tool compare to Sound Forge (e.g. versions 5 and 6) in terms of capabilities and ease of use?
A lot of people are mentioning the "numbers game."
..."
This may explain why when I call 411 on my cell phone, most of the time the reps hang up (redirect to the phone number) after I tell them "Yes, that's the one." As I'm opening my mouth to say "Can I have the exact address?", I hear the automatic "We are now placing a call to
BTW, unlike MADD or a rambling lunatic, I'm going to back up every claim with a link.
MADD (and NHTSA) grossly overexaggerate their claims of "drunk driving accidents," which are really alcohol-related accidents (a misleading statistic used by NHTSA). Did you know that if you, while 100% sober, hit a drunk pedestrian, it counts as an alcohol-related accident? Or did you know that if you get in an accident and EVERYONE is sober (driver, pedestrian, passengers), you can still be counted as alcohol-related due to the statistical correction that NHTSA uses, since only 63% of drivers are tested for their BAC level!
MADD claims that 0.08 BAC reduction saves lives, yet a study by NHTSA found no proof of such reduction after North Carolina enacted the lower BAC limit: "There appears to have been little clear effect of the lower BAC limit in North Carolina. Survey data indicate that the general public believes the new law was well-publicized. Although awareness of the new lower limit was not particularly high nearly 18 months after the law took effect, frequent drinkers did evidence a substantial degree of awareness that the law had changed and about what the new BAC limit was. As is typical in North Carolina, enforcement of the lower limit was vigorous and strict."
MADD wants to lower the BAC limit lower and lower, to 0.05. It claims victory over the 0.08 law over the previous 0.10 standard. However, it has been found that "the relative risk [of being in a traffic accident while using a cell-phone] is similar to the hazard associated with driving with a blood alcohol level at the legal limit." The legal limit in that paper was 0.10 BAC. Another interesting note is that "These data also call into question driving regulations that prohibit handheld cell-phones and permit hands-free cell-phones, because no significant differences in the impairments caused by these two cellular devices were found.", but that's another topic of conversation.
Point is, why do they want to keep lowering the BAC when it has been shown that the vast majority of drunk driving accidents occurs with drivers with over 0.10 BAC, and that below that, it's as risky as using a cell phone? Why is MADD targeting low-BAC-level drivers, such as 0.08 (and as they hope 0.05), with huge fines, property confiscation, loss of driver license, and obscene insurance surcharges? MADD wants to bully states into the 0.08 BAC law by passing legislation that threatens their funding.
Furthermore, when NHTSA's accident data was loaded in a database and independent statistics were ran on it, the massive exaggerations were exposed. Quote from the previous link: "Through the use of this tool we were able to discover that across the entire country NHTSA nearly doubles the number of instances of drunk drivers. And this is prior to them implementing their "Multiple Imputation" methodology w
I wicked agree... that GoogleWatch site is full of crap. Same stuff applies to Yahoo, IMDB, AltaVista, any other search site.
The fact is that your search queries are logged no matter what search engine you are using. If you follow a link from one website to another, the other web site can log where you came from.
Not long at all:
Airport in France. American and German leaders meet. As the French come to the American airplane, George W Bush comes out, sniffs everyone from the French delegation, picks up some dirt off the ground, puts it in his pocket and returns to the airplane.
A few minutes later an American scientist apologizes: "We messed up: instead of the Presidential visit program, we loaded up the Mars rover one".
(apologies to the original poster)
Jan 28, 1986, date of Challenger's launch.
The President of the United States gets a call from Russia's Prime Minister, Mikhail Gorbachev:
- Hello, President?
- Yes?
- Please accept our sincere apologies for Challenger's explosion!
- But it's scheduled to launch in 40 seconds!
- Oh? Ok, we'll call back!
That's not correct. Next time, please say "according to blah,
According to the Mono faq:
So in short, yes, you can compile C# and C++ to bytecode under Windows and run it under Linux.
Although what you said about CLA (being able to call other languages' functions) is correct.
Coming from old DOS Borland interfaces (e.g. for Turbo Pascal), from Visual Studio interfaces, from a bunch of others, I find Eclipse to be rather well-done, relatively non-frustrating (unlike *ahem* vi and emacs). Eclipse really is very good. The code assist features are a fanstastic time saver.
Have you considered that maybe you were doing something wrong? What about Eclipse-- it looks pretty much the same (and correct) to me in both GNOME and Windows.If you want complete control over look and feel, use Swing. It's actually a *benefit* that the look and feel is specific ot a platform.
Can you provide arguments as to why Intellij is better? Or why it's the only sensible choice? (pretending to be like you)Personally, I don't think you're very good at writing software, or making substantiated arguments, so you should stick to reading Slashdot.
But really, IBM has some great software out (the alphaworks site, for example), and Sun didn't make the worst language ever either.
With my Palm, yes! Must've read four books w/ it in locations ranging from subway to bed to toilet.
Having served as a "tech support boy" to my family and their friends and their friends' friends back in the day, and having been around different environments with different kinds of people using computers, I have witnessed many a bright person do things that to us, educated computer geeks, would seem either silly, stupid or overly complicated.
So you're going to tell me that an estemeed professor, who has written many papers (or an executive of a successful non-tech company), who has trouble using what we consider basic computer programs... you're going to tell me that he's an idiot and is only qualified to operate an Etcha-Sketch?
You're full of it. Write me a physics paper.
Everyone on Slashdot owes it to themselves to go out and read "Inmates are Running the Asylum" by Alan Cooper (I read mine in a local library). You will be enlightened to no end.
I'm sure that a lot of Windows driver developers will enjoy porting their drivers over to the Linux architecture.
Actually, there's a story behind Zarro Boogs. It is a Mozilla.org (or probably Netscape) term "yeah, we think there are no bugs, but we won't say it so that you don't hold us to it." For example, a milestone reaches "zarro boogs".
NMS Communciations provides Linux drivers and support for their boards (as well as Solaris and Windows).
Electrical engineers (working on radios) don't design the radios: they design the electronics. An industrial designer designs the radio. Both electrical engineer and industrial designer are quite apt at their job and come together to design software.
Software engineers typically design their software's interfaces, as well as the software's internals. There are usually no user interaction designers involved. That's a problem and what you described about gnucleus is just one example. The software engineer, I bet, does his job quite well, but he just doesn't have the knowledge and experience to develop sensible interfaces.
On another thought, I do remember that one radio I had... I swear an engineer designed it.
Quoting the original poster:
So I don't agree with the "no plugins" argument (just go and download the darn things), but the rest are serious problems.
However, it's alpha! Why treat an alpha release like the final product? So, another poster said:
So any Windows Trillian or AOL AIM users who have tried WinGAIM and have experiences to post?
When I think funky, I wanna get down! But it ain't so wit' this sheit--why you labelin' it like that?
Does it have a funky groove? Does it move to tha beat? Does move that booty smooooth?
Nah, it's all mechanical, soulless, lifeless.. it just ain't got tha funk, brutha!
Creating a branch is very much like copying all the source to another directory (e.g. you had all your source in mysoft directory, which is your trunk.. when you branch, you copy that to mysoft2 directory and now you have a branch.. best of all, every new branch takes up a miniscule amount of disk space, storing only the files you actually change). And then Perforce supplies you with powerful integration tools to let you synch changes across branches.
It has some flaws, like no version control on client, branch and label specs, so if somebody messes up the definition of a branch, you can't step back to the last version, but otherwise it's an excellent source code management (or whatever the right term is) system.
If anyone's curious about P4, they can read the manual.
BTW, Bobby Prince is the composer of all of Doom's music, hence him recording all these songs (as opposed to just being a guy that happened to record them to CD).
But yeah, the CD is awesome and I'm glad that I own a copy :)
And finally, a while ago I made a little remix of Doom's E1M1 soundtrack (3.08MB).
Yep, there are actually quite a few DJs who play using CDs. Vast majority of clubs have CD decks available in addition to the turntables.
:).
Now whether the CDs played are audio CD-Rs with decoded MP3s is a different question
I hear your argument a great deal. I used to think the same thing, but I've changed my opinion of the last couple of years.
For once, the car analogy is moot. Not knowing how to drive a car can quite possibly hurt and kill people. Computers, on the other hand, aside from very limited appliations, are not as fatal.
If cars were not as deadly as they are, people would learn how to drive them the same way they learn Word.
"Computer literacy" is the excuse of computer industry for difficult to use software. It's great for companies to say "the user needs some training" and then ease their development effort by not having to worry about improving usability.
Users should not have to be "computer literate" to get e-mail. Or browse web pages. Or write documents. Or use an accounting program.
Why must every computer user these days know the difference between RAM and hard drive? And everyone must, because every program forces the concept of "unsaved" documents upon users. Have you ever, in real life, had an "unsaved" letter or a journal? When you take a journal off the shelf to write something in, do you make an "unsaved" copy to work on and leave the original on the shelf or do you just take the damn journal off? And does your shelf ask you whether you really want to save your journal when you put it back? No! So why do computers do that?
There are many people out there who have accomplished a lot in their lives, who have respectable jobs and are considered to be great in their field of work. Their kids look up to them and call them smart. But if they have trouble using a computer, and they don't have the time to become accustomed to all the quirks and stupidity that computers inflict on us daily, they will fall behind technologically. They will be considered by "techies" as backward and they will be on the "computer illiterate" end of the digital divide.
And that should not be the case. Computer industry (and that includes both commercial and open-source software) are in denial about the poor usability of their products. When they see people struggling with their software, they label them as as computer illiterate and make fun of them. That's quite a bit like sexism and racism: these folks are being "red lined" and left out behind the red line of "computer literacy."
What necessary is for people that design interactive interfaces to learn proper interaction design. If at least half the programmers out in the world who deal with user interfaces were "interaction literate" (and note the emphasis on interaction and not interface), the world's computers would be much less frustrating to use.
And programmers that deal with user interfaces don't have a good excuse to not be decently versed in interaction design: it's their job.
Finally, a comment about learning. I think that learning is core to all computer use. However, too many interfaces these days impede learning or force much more to be learned than necessary. If one tries to avoid learning, if one builds interfaces solely around concepts that people are familiar with in the "real world" (that is, metaphors), one will fail badly.
Users of computer software never stay newbies--they either learn and become intermediate users or drop off the radar.
Consider the mouse. It's in no way an intuitive device. If you never saw a computer, how the hell in the world would you figure out what to do with this object? How could you possibly figure out by looking at the mouse that it moves the cursor on the screen? You may do some really silly things with the mouse, such as lifting it and moving your hand under it to generate cursor movement.
But as soon as you put the mouse down and move it on the screen, you will see the cursor moving. You will learn how to use the mouse in seconds.
Point is, if learning how to use Kazaa was nearly as easy as learning how to use the mouse, people would use it much more, they would be much more loyal to it, and more people would use it. And things like those described in this article could potentially be avoided.
I may have veered off course a few times in this post--sorry about that. All information presented here is my opinion and not necessarily a statement of fact.
Actually, it's CGA first, EGA, then MCGA and VGA. MCGA was very much like VGA (the most important aspect was 256 colors at 320x200), except it didn't support 16 colors at 640x480, only 2.
Ahh! I just realized it! :o( Sorry, dudle, I take back what I said about you. I feel prey to the same 'skim over, heat up and reply' basic instinct... D'oh! The embarrassment (there goes my credibility, heh...)
I wouldn't call it the Push craze, because that one just sorta fell on everyone, suddenly there's a story about it in every magazine (wasn't that fun reading?)
.NET. For example, if you consider the language-independent object-oriented interfacing, XPCOM, Mozilla's cross-platform component mechansim, is a working technology, and so is CORBA, successfully used by such complex projects as Berlin Consortium. The platform-independent binaries is something Java brought into the light (and boy was there hype at the time), and although not as successfully as expected, it did not fail. However, all of the existing technologies lack one of the big components. XPCOM and CORBA do not provide platform-independence bytecode business, while Java doesn't provide language-independent object communication.
.NET--ignore the marketing, the Passport crap, look at the programming tool, technology that is .NET. So .NET is far from vaporware (would you like to see Visual Studio .NET beta?)
.NET technology (in the general sense) IS a reason to be excited. I honestly want Ximian to drop everything they do and work day and night on Mono, because it will be so damn useful.
.NET is actually a technology that matured to the point where it is now thru a whole bunch of previous experiments, technologies. It started with the Windows OLE, moved on to COM, COM+, DCOM.
There are non-Microsoft technologies, quite a long time in development, that address some of the important issues address by
.NET unites a lot of these things together. Do not look at Microsoft
But back to your point.
So, Ximian, please spend less time making desktops for one operating system and more time changing face of non-Microsoft-bound projects.
You are a good example of the lack of understanding of what .NET entails. While it is true (and, by the way, publicly stated in the Mono FAQ) that .NET has a shitload of marketing and irrelevant tools associated with it, it really IS innovative.
.NET is not innovative and that it is a Bad Thing. That point is nothing but dogmatic. It's like childishly crying "This and that sucks!" It's like a convinced Christian telling you that God exists. You try to argue with him about his religion and come to this one point where you may have some REASON in, but, he sticks the dogmatic argument 'God exists' and that's all.
.NET is described as having superior dev tools, you ask "What if ... I don't know ... do you think ... is it really ... True?" So you just friggin said it's true and now you question yourself.
.NET is a mostly a good thing because of the TECHNOLOGY advancements. The bad thing about .NET is the marketing that Microsoft puts behind it, but that's to be expected. However, describing a technology's benefits is not the kind of blatant marketing that you describe. If I told you that C++ permitted me to write applications in a much more reusable fashion than C, would you tell me in my face that I'm blatantly marketing C++ and that my argument should be discounted?
I know it is hard to comprehend that Microsoft can come up with something innovative, due to the anti-Microsoft mindset of the hoard of Slashdotters, but dig it thru your head. Re-read your post: your whole post is based on the point that
Such is your post. You start off by saying keep an open mind. Fine, and you do admit that "With an open mind you realize that vi and Emacs don't come even close to a fully integrated development environment." Now, in the next friggin paragraph, where
Basically, face it.
And the signal that your post is garbage is when you say "I was waiting for someone like you. You give me the opportunity to make my point." What prevents you from making the point, in this post-anywhere, public forum Slashdot? No, the real deal is that you found somebody you can group with and together bash something and otherwise exhibit single-mind group behavior. Just like the blind anti-MS bashing.
mp3.com/ilp
The IDE issue. Have you developed large software in Linux and using recent Visual Studio? Sure, you can use vi and man, but you do not get things accomplished as quickly or as conveniently. vi has a significant learning curve, whereas Visual Studio IDE is sit down and start typing, and man is not as quick and convenient in retrieval and cross-referencing of the information. Compare putting cursor over the API call you just typed, pressing 'F1' (or is it Ctrl+F1? some keystroke, anyway) in Visual Studio IDE and getting a documentation page, then scrolling down, clicking on a related function and getting the help for it. Think of doing the same function with vi and man. Not nearly as convenient. And does man have cross-referenced, searcahble and indexed tutorials, guides, overviews, references to obscure APIs or APIs that may not be installed on the system? Point is, developing with Visual Studio is just damn convenient, and there are very few Linux tools in development that begin to approach the quality of the Visual Studio IDE. Take it from someone who coded both on Windows, Tru64 (Digital Unix back then), Solaris and Linux.
The DLL issue. This is where you missed the point so far it's not even funny. You are talking about versioning problems (old libraries and such). Now, tell me, if Miguel makes such a big deal out of versioning problems, why isn't it even mentioned on the Mono FAQ page or the issue touched/discussed at any kind of length anywhere? I bet the answer's gonna strike you like a heart attack strikes Dick Cheney: Miguel isn't talking about versioning. There is NO DLL hell (believe me, the versioning problems are not near the hell Miguel has in mind) when you are developing libraries using a statically-typed, procedural language like C. That's because the .so and .dll dynamic library mechanisms are designed to provide procedural APIs (i.e. APIs consisiting of statically-typed functions) and they do it well.
However, if you have ever tried to use object-oriented languages such as C++ with either of the DLL mechanisms (they are for all practical purposes the same) and tried to either provide an object-oriented API or use an object-oriented API, you will learn what the DLL hell means. It means that there is no elegant, straightforward solution to having object-oriented APIs with the DLL mechanisms, everything is a kludge, a hack. And the widely-used hack of exposing the object-oriented API thru a few access C methods (and lotsa casting), means that the client of the library must use the same ABI. And what does that mean? That means constrained to the same programming language, the same compiler (compilers often have different ABIs), and even to certain versions of the same compiler if the ABIs change from version to version. So the DLL hell is when you see a gcc-2.95-built C++ library that you'd love to use in your Delphi app, but you can't. You can't use the Solaris C++ compiler with that library. You can't even use gcc version 3.0 with that library, unless you force it to use the older ABI. (I may be wrong as to exactly which versions of gcc have the differing ABIs, but the point stands.)
I'll give you a real life example. There is a fabulous, free Windows app called Buzz. The plug-ins for that application must all be written in C++ and compiled with Visual C++. In other words, poor, yet talented developers (and in smaller European countries there are plenty) who can't afford Visual C++ 5.0 or 6.0, can't use their existing Delphi or Borland C++ compiler or the win32 port of gcc compiler. Intel C++ compiler? Fogghetaboutit. Raw talent can't contribute--just because the object-oriented-API-enabling DLL hack forces that to be the case.
You don't feel nearly as much heat in the Linux environment because nearly damn everything is built with the same compiler, using close versions (and using C). But you go to some Unix OS machine where the OS and a lot of the libraries are built using the vendor's provided compiler and you taste the hell. You try using an object-oriented Pascal compiler (FreePascal) with a C++ library and you're shit out of luck. Have Python use that C++ library? Can't do directly, gotta write messy translation layers. Same goes for almost any scripting language. Should I keep going with the examples or do you get the point?
Now compare that to Mono. Mono will let you write an OO API library in C++, and use it from something like Python like a normal object, with very little syntactical moronisms.
<bitchsession>So don't label Miguel as a Microsoft cheerleader in hopes of getting the Slashdot crowd moderating your inattentive butt up. And take that 'must consider only one view, must stick to one view' way of writing "eloquent" speeches and high school essays and stick it up where the sun don't shine. Because the world is gray and while Miguel may not subscribe to your views, labeling a developer that contributes so fucking much to the Linux community as a puppet of the Microsoft marketing machine is purely ignorant and ungrateful. In fact, as an aspiring software engineer, it hurts me that you dare use words "rational software engineer" with such an ignorant, non-software engineer viewpoint, as any rational, experienced software engineer that practices object oriented programming will tell you that anything that promotes reuse, avoids having to write a ton of extra code and avoids the above-described real DLL hell, is going to look at this free, open-source initiative (Mono) and say "Thank god, I was waiting for this." You do not nearly realize the kind of freedom and the kind of time savings that Mono will yield in medium and large software projects, something that was previously avaialble only on the Windows platform and for a shitload o' money (Windows + all the dev tools).</bitchsession>