(a) I don't see what their name has to do with this
(b) The name is pretty par for the choice for a lobbying group
(c) In this case, the name is actually deserved, as what they're fighting for is not to ban Open Source software from government contracts, but only to ensure that the US government not *require* Open Source, which would eliminate as an option most current closed software.
No, I don't think *gentoo* is bogus. I said that this "Gentoo runs faster bit" is bogus. I just think that the gentoo advantages lie in the software distribution stuff (frankly, I'm not a tremendous fan of up2date, which is probably RH's weakest point), and possibly some of the layout things....you do your test on RedHat
No, it's not a methodology problem -- the people claiming that gentoo is "blazing fast" are talking about the fact that it's built with optflags for your processor. That's precisely what I did.
which version of gcc did you use
I don't remember which one...it was the latest one out at the time. Probably either 2.96 or 3.0 something. I not infrequently use rawhide based gcc.
You will have to "remove" a lot of stuff _after_ installing
Okay. I didn't say that gentoo didn't have advantages -- just that this claim of a big performance advantage is unwarranted.
you will have to get the latest stable gcc, and to recompile everything from srpms
But that's my point -- that there *is not* much benefit to simply recompiling, so it's not really worth the trouble of recompiling.
Oh, don't get me wrong -- building from source is important for stuff you want devel versions of (gtk-gnutella, gimp), or want specific features compiled out (rxvt). I'm merely addressing performance issues -- saying that simply recompiling everything on your system is not a big benefit.
This whole "gentoo runs faster" bit is, frankly, bogus.
(a) all the major distros ship multiple versions of crucial stuff like the kernel and glibc, where the cycles actually matter. (b) At one point, I flipped the optflags to build for my processor and rebuilt everything significant in my RH install at the time from SRPMS. Reinstalled. No significant speed improvements.
RedHat installs cron, you don't have any choice about it. cron needs sendmail
Umm...I don't have an older version handy to check, but this is definitely not true in the current version of RH (8.0). Furthermore, I've been using postfix instead of sendmail for quite some time, with no warnings. I think that your information may be either out of date or incorrect.
And while some people may not want cron, for most people who want a UNIX-like system, it's pretty fundamental, and there's little cost to having it.
I believe most distros are in the 3.x era now (and thank God, because it's a significant improvement). At least Mandrake, SuSE and Gentoo ship with a 3.x gcc, and I suspect most others.
I switched to gentoo about 6 months ago, and I have learned more about linux in those 6 months...
Okay, I've heard this a lot. And I don't buy it as a good justification.
There are two types of users out there -- those who want it to "just work" and those who want to learn the thing inside and out. The first are better off using a distro that "just works", and the second aren't being *restricted* from playing with the guts of, say, Red Hat...they just aren't *required* to. RPM is sgreat -- it's a great, automated system to track versions of installed software and yank out entire packages at a time. But it's hardly a barrier to getting your hands dirty -- you don't have to use Slackware to write config files manually, do custom initscripts, and customize your bootloader.
And you're claiming that it's not, simply because you like it. I'd say that my criteria are at *least* as valid.
Nah, your best bet are zeros and ones
Except that isn't usually the case. It simply isn't reasonable for a human to know all the timings for the various chips they're targeting and write perfect code any more, and even if they could, CPUs are too complex, and compilers too good. Rasterman, who writes a good deal of low-level code to do graphics stuff very quickly (and hence knows x86 assembly better than most), recently wrote how he spent a huge amount of time rewriting a C library in x86 assembly, and got no real speedups in his hand-tweaked one. Even tiny embedded systems are leaving assembly in droves, because compilers are *good* these days.
Plus, targeting multiple x86 processors, where you might have obsolete opcodes implemented in microcode or optimal alignments might change isn't really reasonable for much of anything.
I wouln't call Java's support bolted on. It's language level as well."
Ah, ah, ah, it still depends on pthreads. Pthreads isn't native.
Your statement is simply nonsensical. Feel free to show Slashdot a place in the Java spec where it says "implemented JVMs shall utilize the pthreads library".
Non-preemptive threads
Fine, non-preemptive threads. It doesn't help me unless I want to write a program with thousands of *non-preemptive* threads....scalability is mostly irrelevant. Not for everybody.
Fine, let me clarify it. Scalability, the sort of way Sun is selling is (which translates to "you can add more hardware to get some reasonable amount of performance increase" is totally fucking irrelevant to almost every software package in the world. Yes, perhaps erlang is useful for 80 node setups (I'm not saying it is, just that I don't care enough to try to find out). I (and the overwhelming majority of other people) are not working with 80 node setups, and the interesting factor is whether performance sucks on a single node system.
Your problem seems to be Swing, not Java.
No, in fact, it is *not* Swing. There are plenty programs with Java components that do not use Swing -- and they're *still* slow, and it's *still* because of the Java bit.
Furthermore, JVM isn't the only way to implement Java.
And this is totally irrelevant to the discussion, because running a Java program in IBM's JVM is the fastest way to run Java on Linux. No existing Linux native code compiler produces code of equivalent quality. So unless you want Java to appear even slower than it actually is, you're going to be talking about running in a JVM.
So if they've improved performance over the years, it can't be done anymore for some imaginative reason? Garbage.
No, it's simply massively trailed off. All the big issues with the implementations (well, the major ones, like Sun's and IBM's) have already been worked out, and there isn't much left to be fixed. If you'll look at the improvements of JVMs since...oh, I don't know, '99, they've been pretty steadily trailing off. There are fundamental issues with Java at the language level that cap performance, which I listed earlier in this thread.
Right, like some end-user GUI stuff. Performance critical indeed.
Yes, actually that *is* performance critical. Feel free to reimplement SDL or GTK in Java while I laugh. Very few pieces of software on a PC-or-larger system are as performance-critical as real-time stuff that a user is interacting with, like games or a word processor. It doesn't really matter if my backup server has 30% worse performance, but it does if Quake does.
Also, you took issue with my link to Bagley's Language Shootout page...yet that page deals almost exclusively with core computational operations, not "end-user GUI stuff".
'fputs' isn't broken? Can you say buffer overflow by design?
Have you ever actually *seen* or *used* fputs()? I'd love to hear what "buffer overflow" you're thinking of, because I don't think you have the faintest idea what you're talking about.
Reread my last response
Yup. I rebutted the points in it that were relevant.
This is a library written by someone.
It doesn't add keywords -- it *is* extending the evironment that I'm writing in, however. This is also completely irrelevant, because the semantics don't matter -- only whether the missing functionality is present. Which it is.
C is definitely slower than assembly on micro-benchmarks, and even otherwise. Orders of magnitudes slower. Your point?
[laughing my ass off] Okay, "orders of magnitude", eh? Before making a damn fool of yourself any more, run out and find yourself a benchmark where your C compiler produces code that is a *hundred* times slower than your hand-coded assembly. This should be entertaining. Find me...oh, a matrix multiplication benchmark, say, where assembly is 100 times faster than a C compiler can generate. I'd love to see what flaws *in the C language* you can find that would ever make C 100 times slower than assembly. The flaws I pointed out in Java were *in the language itself*.
What are you claiming is not true in what I said? Phoenix is a web browser, Moz is a "communications suite". That isn't really arguable.
Perhaps that a single #define will determine whether you get phoenix or Moz from the Moz codebase? That's just the way it works. Check out moz from cvs and use MOZ_PHOENIX=1 when compiling.
Sure. You want a web browser these days, you use Phoenix. You want a "communications suite" that lets you chat, send email, etc, you get Mozilla. Different goals.
Of course, since you change a single #define and then compile Moz to get Phoenix, I'm not sure that you can really say that you aren't using Mozilla...
A congressman...who cares about the interests of individuals in the tech world? This wouldn't be our good old, oft-lauded on Slashdot friend Rick, now would it?
Funny as this is (IT department demands users use MacOS, users refuse and want to use Windows), there's a simple fix. If these folks are so computer-centric that they can handle this themselves, let them run (as an alternate...I'd put a normal, supported computer on their desk so that they're never in a situation where they can say "hey, I can't do X and the IT department won't help") Windows. Make them admin the box themselves too, and state very clearly at the outset that connecting a nonstandard box to the network is a privilege, not a right, and at the first onset of problems, the box goes permanently.
A lot of Windows networks have Linux boxes creeping on to them via this route -- the users have to admin them, and are fully responsible if anything goes wrong.
I'd also put a few hard rules on the users -- if they break them, they're in violation. First, SMB/CIFS goes. Windows file sharing causes more problems than anything else on earth. Second, it's probably not a bad idea to budget to get them antivirus programs. Third, I wouldn't let them run their own servers (IIS or whatnot) unless this is already a normal policy (users running servers is kosher) and you have them blocked from the outside world -- users simply do not reasonably have the time if they're doing their work to keep servers up to date.
That being said, your job is to allow the users to get their work done as efficiently as possible. If they're uncomfortable in a non-Windows environment, don't make yourself disliked by trying to impose a different environment on them. Make reasonable restrictions, as I noted above, but don't axe their desires just because they're Windows-based.
I'd try this approach regardless of the OS being used, if it's an unsupported OS, as a matter or fact.
Oh, and the last item: you may (I feel reasonably) ban the use of Outlook on your network. People can argue as much as they want about whose fault Outlook issues are and whether Outlook is simply targeted because it's popular, but there have been enough nasty worms and problems coming from Outlook that I don't think I'd want to administer a network with it on it.
Let me prepend this by saying that I really do not like ocaml or other ml languages, but if you're into functional languages, you may like it. There are some things that are done right, like a very strong type system.
Unison, a file-sychronization tool, and MLDonkey, a P2P client that supports just about every significant P2P protocol out there (except the closed version of FastTrack) are both written in ocaml. That's all I know of, though.
Give me something like ocaml but without type inference (most annoying invention of all time) and not a functional language (sorry, just don't think that way), and I'd be pretty happy. It's about the fastest safe language out there, followed closely by eiffel.
I know some people use languages in which programs can be proven to work like ML
Oh, the languages can be proven to work, eh? When you produce a compiler that can prove that your *arbitrary* program ever stops, much less does A, B, or C, come see me, because we'll have tons of fun turning the entire mathematics and computer science worlds upside down.
If you just mean human-provable, and only for small non-arbitrary programs, that's quite doable with C or any other language. ML makes it slightly more structured, which is convenient, but doesn't give you anything that you couldn't do with C.
it's absurd that they don't provide it to the veyr people that freely provided them with tools that they have rebadged as their own (sunssh) and tout as a feature
Okay, it may not be a good idea for Sun, but I don't see why people are bashing Sun for it.
First, the OpenBSD people choose to release openssh under a BSD license. Sorry, but you *cannot* "expect" anything in return, not even morally (IMHO) -- the BSD license is not a "nicer sounding" closed license. Sun isn't obliged to do jack in return, any more than the BSD people are obliged to do jack in return for Sun donating personnel and resources to the GNOME Usability Project.
Second, Sun makes their money from hardware, not from selling Solaris. This is much more of an issue to Sun than the OpenBSD people. I can't understand why the OpenBSD people even care -- if Sun doesn't want the OBSD people to further increase the value of Sun hardware, that's a Sun issue, not an OBSD issue. Leave it.
Third, this article was fairly obviously designed to start a *BSD-Linux flamefest ("But those bad ol' Linux developers, *they* got the documentation"). I'd just ignore falling into the trap the article author laid for you, Slashdot posters.
Actually, send them an invoice for your time and upset in having to read an article about them on Slashdot. It makes as much sense as random organizations sending out bills to people, regardless of what the reason is.. You can even threaten to sue them if they don't pay up.
I utterly cannot understand why people are getting the least bit upset over this. It simply does not matter.
The "opportunistic recording" thing is a feature. If you have some blank hard drive space, it'll grab extra stuff for you. Why anyone would *care* that it grabs something that you don't want is beyond me.
It should never *hurt* you, thought it might not get something you could have liked and fail to help you.
Okay, you're right about the default settings. He screwed up.
I'm not saying that icons cannot be useful, but I tend to find that the value of them is significantly oversold.
I didn't realize that the links all went to the same "under construction document"...I didn't actually check out what he was doing. Good call.:-) I understand the implications for the user of having links go to "under construction" pages, but ideally you'd have few pages "under construction", and the cost is not that high. It may not be ideal (having some software system to handle these sorts of internal links might be helpful), but it's certainly got some reasoning behind it.
Javascript is not bad
I'm not saying it doesn't have its use. I just really get annoyed when people use it for regular links (or even to open "preview windows", come to think of it...there's an extension to do that with HTML, IIRC. Usually I think that "preview windows" are a bad idea -- if I want a new window, I'll open a new window or hit the back button).
You're right about the lack of alt text and the fact that it was made with Front Page is a bit funny -- but FrontPage doesn't necessarily generate awful HTML (based on the source of a few websites I've seen), at least if you avoid all its extensions.
I would really like to hear what alternative ideas you have
Oh, lovely. Put me on the spot. Much easier to gripe than fix.
Well...given that I'm a hardcore anti-frames type, I'd probably do things on a page of my own in the traditional HTML style -- if the content isn't too large, on one page with the TOC at the top with links to anchor tags in the text, and if there are a *lot* of poems, links to either "yearly" pages with poems or individual poem pages.
What would probably be more acceptable to you would be simple enlarging the frame containing the Table Of Contents(TOC). If someone has to scroll to read a poem, no great loss. They're more likely to read a poem linearly, and random-access the TOC, and the TOC gets more use, anyway.
my own site a bit more of an artistic toy
The "it's a hobby site" objection is pretty reasonable, and it is undoubtedly the most compatible and usable site of this sort I've used with alternate browsers.
I still think it would be nice to have text somewhere on or near the "expanding image" icons so that one doesn't *have* to flip around with the mouse to find the text.
Get one of the Freenet guys (or, if an EFF guy is willing to help out again, one of them) to point out that Freenet is the *ideal* protection against terrorist attacks on the information infrastructure of the United States.
Consider all the "security" grants that are being thrown left and right at companies. They're lapping up all those tax dollars in the form of goverment contracts. If Freenet can grab just one, that would fund development for a long, long time. Lots of improvements, and I'd have a hard time imagining a more worthy cause than a more robust, secure, attack-resistant, private system that makes for more efficient transfers over the network.
The overwhelming majority of my university's CS research funding comes from the Department of Defense. Freenet couldn't snag just a few of that flood of dollars going to organizations aroudn the country?
So you're from one of the "broad generalization" camps.
Oh, stereotype me, will you.:-)
[snip long passage about how Erlang concurrent programming is good]
Look, I don't have a problem with Erlang as a language. There are, I'm sure, lots of good applications for it. The problem is that I'm looking for a language that focuses on speed, which there is a decided paucity of recently. Despite all the compiler improvements and optimization techniques developed, the fastest choice around is generally *still* C and C++, the first of which is *decades* old, and the second of which has a lot of old baggage.
I want modern functionality with even *better* speed. That's all. Erlang is not what I'm looking for, but that doesn't mean it's not good for some people.
In Java [threads are] an alien invader _bolt-on_ with all the resulting invonveniences and OS-dependence.
I wouldn't call Java's support bolted on. It's language level as well.
Erlang applications scale well with thousands of threads
That's nice (I was quite impressed with CML, which has similar capabilities), but it doesn't really help me unless I'm dead set on writing a program with thousands of preemptive threads.
How fast and how fast for solving which problems
Horizontal market, end user stuff like the desktop programs I mentioned. A web browser. A word processor. A photo manipulation program. A vector graphics program.
Java has been used to write a scalable application framework which has been used to write a web server which scales better than an equivalent C-based server. See http://www.cs.berkeley.edu/~mdw/proj/seda/
Your link (well, what should have been a link) is dead. And scalability is mostly irrelevant. Sun sold lots of copies of Java on the "scalability" argument, but on the level you're talking about, it's not germane to my issues, if I'm writing something for a single node. I can make a scalable system too: T=1000yrs + 1 sec * N, as opposed to T=2 sec * N. Remember, Sun cares about selling hardware, preferably lots of hardware. The biggest draw of their product is that you can "trade up" easily. So they make a slow language that lets you "trade up" easily. And surprise, they push the language. Shocking! Java may be sexy for Sun's target market, true, but not for people like me.
Your broad generalization that Java is slow in any case, any kind of application, anywhere (just because you have this idea in your head), falls flat on its face.
Saying "Java is slow" has some quite obviously understood implications by both you and me, so don't play stupid. That doesn't win any arguments. Java may well be faster at...oh, I don't know, closing. For the vast majority of cases, if I want to sit down and write something that a user interacts with, a Java program is much more sluggish than a C++ program. This is not something that I'm the only one trumpeting -- anyone that's used Java has run into this. And don't give me the "you're using a slow JVM" bullshit that Java advocates love to spout -- I've been developing exclusively with IBM's JDK. There isn't a faster JVM out there for Linux.
"Profile, don't speculate".
Okay. The Java software that I've used is, without exception, sucks down CPU cycles and RAM. Freenet is slow. The theorem-proving environment that Carnegie Mellon University uses for logic courses is slow. Another game-theory environment I've used is slow. Tube (a Java hotline client and library) is mind-bogglingly slow. Now, perhaps I just *happened* to run across every single slow Java application, and just *happened* to run across every single fastest C equivalent, but I don't believe it.
Don't confuse language with a language implementation. If you sacrificed language features to speed -- like it has been done with C, chances are they will never be added to a language later....if a language _implementation_ suffers from performance problems, they can always be dealt with later.
I have macros that both allocate, test for the proper allocation, and typecast the allocation of a struct in C. I use an excellent object-oriented C environment with glib and gtk. I have named constants. The C environment that I use today is far nicer than that three decades ago.
As for your claim that they can always be dealt with later in the implementation, I have an excellent counterexample -- the JVMs that you're so staunchly supporting. When Java was released, it ran like a dog. Sun promised that better compilers would improve things. Optimization got a little better. JITs helped. And you know what? Java is, indeed, faster than it once was. It is *still* sluggish, however. And it's not going to improve much more. And the *language* has limited this -- the lack of typed container objects, the required bounds checking, the almost-impossible-to-avoid reliance on heavy heap-based dynamic allocation of memory. No implementation can fix this. Java as a *language* is terminally limited to never run faster than at a certain clip. Now, it's still quite useful for many things, but not for performance-critical stuff, which happens to matter to me.
Case in point C's string functions are not only ugly...
I'll definitely agree with you there....but broken.
And I won't agree with you there.
If language designers wanted to extend the language with new string functions that allocated memory -- how easy of a change would that be?
Really, really easy. Look at glib for C or any one of many, many good string classes for C++.
Premature optimizations in language design, or application design are equally evil.
Are you unbelivably asinine? "Premature optimizations in language design"? How do you think someone is going to "prematurely optimize" a language spec? Do you want to wait until a language is widely used and *then* run out and make lots of changes to it? Heck, that isn't even relevant. I've been talking about existing languages, which are already well understood. There is no prematurity here at all....you'll realize it's all about trade-offs, and speed is secondary to other goals of language design.
And one day, *you* will realize that having a speedy language does not entail *losing* other functionality.
Except your faster language will probably result in more bugs, more time-to-market, more complexity, and more poeople overhead because it wasn't suitable for solving the problem at hand in the first place.
This is coming from the same person that just asked someone not to "generalize" about programming languages. How the hell did you reach the conclusion that speed entailed a lack of safety or an inability to do rapid application development?
Slashdot Mirror
group called "Initiative for Software Choice"
(a) I don't see what their name has to do with this
(b) The name is pretty par for the choice for a lobbying group
(c) In this case, the name is actually deserved, as what they're fighting for is not to ban Open Source software from government contracts, but only to ensure that the US government not *require* Open Source, which would eliminate as an option most current closed software.
This is, without a doubt, the best way to get advertising as well.
you said "this gentoo thing is bogus"
...you do your test on RedHat
No, I don't think *gentoo* is bogus. I said that this "Gentoo runs faster bit" is bogus. I just think that the gentoo advantages lie in the software distribution stuff (frankly, I'm not a tremendous fan of up2date, which is probably RH's weakest point), and possibly some of the layout things.
No, it's not a methodology problem -- the people claiming that gentoo is "blazing fast" are talking about the fact that it's built with optflags for your processor. That's precisely what I did.
which version of gcc did you use
I don't remember which one...it was the latest one out at the time. Probably either 2.96 or 3.0 something. I not infrequently use rawhide based gcc.
You will have to "remove" a lot of stuff _after_ installing
Okay. I didn't say that gentoo didn't have advantages -- just that this claim of a big performance advantage is unwarranted.
you will have to get the latest stable gcc, and to recompile everything from srpms
But that's my point -- that there *is not* much benefit to simply recompiling, so it's not really worth the trouble of recompiling.
Oh, don't get me wrong -- building from source is important for stuff you want devel versions of (gtk-gnutella, gimp), or want specific features compiled out (rxvt). I'm merely addressing performance issues -- saying that simply recompiling everything on your system is not a big benefit.
This whole "gentoo runs faster" bit is, frankly, bogus.
(a) all the major distros ship multiple versions of crucial stuff like the kernel and glibc, where the cycles actually matter.
(b) At one point, I flipped the optflags to build for my processor and rebuilt everything significant in my RH install at the time from SRPMS. Reinstalled. No significant speed improvements.
RedHat installs cron, you don't have any choice about it. cron needs sendmail
Umm...I don't have an older version handy to check, but this is definitely not true in the current version of RH (8.0). Furthermore, I've been using postfix instead of sendmail for quite some time, with no warnings. I think that your information may be either out of date or incorrect.
And while some people may not want cron, for most people who want a UNIX-like system, it's pretty fundamental, and there's little cost to having it.
I believe most distros are in the 3.x era now (and thank God, because it's a significant improvement). At least Mandrake, SuSE and Gentoo ship with a 3.x gcc, and I suspect most others.
I switched to gentoo about 6 months ago, and I have learned more about linux in those 6 months...
Okay, I've heard this a lot. And I don't buy it as a good justification.
There are two types of users out there -- those who want it to "just work" and those who want to learn the thing inside and out. The first are better off using a distro that "just works", and the second aren't being *restricted* from playing with the guts of, say, Red Hat...they just aren't *required* to. RPM is sgreat -- it's a great, automated system to track versions of installed software and yank out entire packages at a time. But it's hardly a barrier to getting your hands dirty -- you don't have to use Slackware to write config files manually, do custom initscripts, and customize your bootloader.
because some microbenchmark says so
...scalability is mostly irrelevant. Not for everybody.
And you're claiming that it's not, simply because you like it. I'd say that my criteria are at *least* as valid.
Nah, your best bet are zeros and ones
Except that isn't usually the case. It simply isn't reasonable for a human to know all the timings for the various chips they're targeting and write perfect code any more, and even if they could, CPUs are too complex, and compilers too good. Rasterman, who writes a good deal of low-level code to do graphics stuff very quickly (and hence knows x86 assembly better than most), recently wrote how he spent a huge amount of time rewriting a C library in x86 assembly, and got no real speedups in his hand-tweaked one. Even tiny embedded systems are leaving assembly in droves, because compilers are *good* these days.
Plus, targeting multiple x86 processors, where you might have obsolete opcodes implemented in microcode or optimal alignments might change isn't really reasonable for much of anything.
I wouln't call Java's support bolted on. It's language level as well."
Ah, ah, ah, it still depends on pthreads. Pthreads isn't native.
Your statement is simply nonsensical. Feel free to show Slashdot a place in the Java spec where it says "implemented JVMs shall utilize the pthreads library".
Non-preemptive threads
Fine, non-preemptive threads. It doesn't help me unless I want to write a program with thousands of *non-preemptive* threads.
Fine, let me clarify it. Scalability, the sort of way Sun is selling is (which translates to "you can add more hardware to get some reasonable amount of performance increase" is totally fucking irrelevant to almost every software package in the world. Yes, perhaps erlang is useful for 80 node setups (I'm not saying it is, just that I don't care enough to try to find out). I (and the overwhelming majority of other people) are not working with 80 node setups, and the interesting factor is whether performance sucks on a single node system.
Your problem seems to be Swing, not Java.
No, in fact, it is *not* Swing. There are plenty programs with Java components that do not use Swing -- and they're *still* slow, and it's *still* because of the Java bit.
Furthermore, JVM isn't the only way to implement Java.
And this is totally irrelevant to the discussion, because running a Java program in IBM's JVM is the fastest way to run Java on Linux. No existing Linux native code compiler produces code of equivalent quality. So unless you want Java to appear even slower than it actually is, you're going to be talking about running in a JVM.
So if they've improved performance over the years, it can't be done anymore for some imaginative reason? Garbage.
No, it's simply massively trailed off. All the big issues with the implementations (well, the major ones, like Sun's and IBM's) have already been worked out, and there isn't much left to be fixed. If you'll look at the improvements of JVMs since...oh, I don't know, '99, they've been pretty steadily trailing off. There are fundamental issues with Java at the language level that cap performance, which I listed earlier in this thread.
Right, like some end-user GUI stuff. Performance critical indeed.
Yes, actually that *is* performance critical. Feel free to reimplement SDL or GTK in Java while I laugh. Very few pieces of software on a PC-or-larger system are as performance-critical as real-time stuff that a user is interacting with, like games or a word processor. It doesn't really matter if my backup server has 30% worse performance, but it does if Quake does.
Also, you took issue with my link to Bagley's Language Shootout page...yet that page deals almost exclusively with core computational operations, not "end-user GUI stuff".
'fputs' isn't broken? Can you say buffer overflow by design?
Have you ever actually *seen* or *used* fputs()? I'd love to hear what "buffer overflow" you're thinking of, because I don't think you have the faintest idea what you're talking about.
Reread my last response
Yup. I rebutted the points in it that were relevant.
This is a library written by someone.
It doesn't add keywords -- it *is* extending the evironment that I'm writing in, however. This is also completely irrelevant, because the semantics don't matter -- only whether the missing functionality is present. Which it is.
C is definitely slower than assembly on micro-benchmarks, and even otherwise. Orders of magnitudes slower. Your point?
[laughing my ass off] Okay, "orders of magnitude", eh? Before making a damn fool of yourself any more, run out and find yourself a benchmark where your C compiler produces code that is a *hundred* times slower than your hand-coded assembly. This should be entertaining. Find me...oh, a matrix multiplication benchmark, say, where assembly is 100 times faster than a C compiler can generate. I'd love to see what flaws *in the C language* you can find that would ever make C 100 times slower than assembly. The flaws I pointed out in Java were *in the language itself*.
What are you claiming is not true in what I said? Phoenix is a web browser, Moz is a "communications suite". That isn't really arguable.
Perhaps that a single #define will determine whether you get phoenix or Moz from the Moz codebase? That's just the way it works. Check out moz from cvs and use MOZ_PHOENIX=1 when compiling.
Sure. You want a web browser these days, you use Phoenix. You want a "communications suite" that lets you chat, send email, etc, you get Mozilla. Different goals.
Of course, since you change a single #define and then compile Moz to get Phoenix, I'm not sure that you can really say that you aren't using Mozilla...
A congressman...who cares about the interests of individuals in the tech world? This wouldn't be our good old, oft-lauded on Slashdot friend Rick, now would it?
Funny as this is (IT department demands users use MacOS, users refuse and want to use Windows), there's a simple fix. If these folks are so computer-centric that they can handle this themselves, let them run (as an alternate...I'd put a normal, supported computer on their desk so that they're never in a situation where they can say "hey, I can't do X and the IT department won't help") Windows. Make them admin the box themselves too, and state very clearly at the outset that connecting a nonstandard box to the network is a privilege, not a right, and at the first onset of problems, the box goes permanently.
A lot of Windows networks have Linux boxes creeping on to them via this route -- the users have to admin them, and are fully responsible if anything goes wrong.
I'd also put a few hard rules on the users -- if they break them, they're in violation. First, SMB/CIFS goes. Windows file sharing causes more problems than anything else on earth. Second, it's probably not a bad idea to budget to get them antivirus programs. Third, I wouldn't let them run their own servers (IIS or whatnot) unless this is already a normal policy (users running servers is kosher) and you have them blocked from the outside world -- users simply do not reasonably have the time if they're doing their work to keep servers up to date.
That being said, your job is to allow the users to get their work done as efficiently as possible. If they're uncomfortable in a non-Windows environment, don't make yourself disliked by trying to impose a different environment on them. Make reasonable restrictions, as I noted above, but don't axe their desires just because they're Windows-based.
I'd try this approach regardless of the OS being used, if it's an unsupported OS, as a matter or fact.
Oh, and the last item: you may (I feel reasonably) ban the use of Outlook on your network. People can argue as much as they want about whose fault Outlook issues are and whether Outlook is simply targeted because it's popular, but there have been enough nasty worms and problems coming from Outlook that I don't think I'd want to administer a network with it on it.
Yup.
I like the Mirriam-Webster website more anyway. Who's to say what dictionary defines the language other than the dictionary's creators?
Let me prepend this by saying that I really do not like ocaml or other ml languages, but if you're into functional languages, you may like it. There are some things that are done right, like a very strong type system.
Unison, a file-sychronization tool, and MLDonkey, a P2P client that supports just about every significant P2P protocol out there (except the closed version of FastTrack) are both written in ocaml. That's all I know of, though.
Give me something like ocaml but without type inference (most annoying invention of all time) and not a functional language (sorry, just don't think that way), and I'd be pretty happy. It's about the fastest safe language out there, followed closely by eiffel.
I know some people use languages in which programs can be proven to work like ML
Oh, the languages can be proven to work, eh? When you produce a compiler that can prove that your *arbitrary* program ever stops, much less does A, B, or C, come see me, because we'll have tons of fun turning the entire mathematics and computer science worlds upside down.
If you just mean human-provable, and only for small non-arbitrary programs, that's quite doable with C or any other language. ML makes it slightly more structured, which is convenient, but doesn't give you anything that you couldn't do with C.
it's absurd that they don't provide it to the veyr people that freely provided them with tools that they have rebadged as their own (sunssh) and tout as a feature
Okay, it may not be a good idea for Sun, but I don't see why people are bashing Sun for it.
First, the OpenBSD people choose to release openssh under a BSD license. Sorry, but you *cannot* "expect" anything in return, not even morally (IMHO) -- the BSD license is not a "nicer sounding" closed license. Sun isn't obliged to do jack in return, any more than the BSD people are obliged to do jack in return for Sun donating personnel and resources to the GNOME Usability Project.
Second, Sun makes their money from hardware, not from selling Solaris. This is much more of an issue to Sun than the OpenBSD people. I can't understand why the OpenBSD people even care -- if Sun doesn't want the OBSD people to further increase the value of Sun hardware, that's a Sun issue, not an OBSD issue. Leave it.
Third, this article was fairly obviously designed to start a *BSD-Linux flamefest ("But those bad ol' Linux developers, *they* got the documentation"). I'd just ignore falling into the trap the article author laid for you, Slashdot posters.
It's theoretically possible to design a distributed filesystem that can handle the failure of one or more nodes.
Kind of an interesting project, actually. I don't recall this being done before.
Actually, send them an invoice for your time and upset in having to read an article about them on Slashdot. It makes as much sense as random organizations sending out bills to people, regardless of what the reason is.. You can even threaten to sue them if they don't pay up.
I utterly cannot understand why people are getting the least bit upset over this. It simply does not matter.
The "opportunistic recording" thing is a feature. If you have some blank hard drive space, it'll grab extra stuff for you. Why anyone would *care* that it grabs something that you don't want is beyond me.
It should never *hurt* you, thought it might not get something you could have liked and fail to help you.
Before long, you'll see...necking!
text the same color as the background
:-) I understand the implications for the user of having links go to "under construction" pages, but ideally you'd have few pages "under construction", and the cost is not that high. It may not be ideal (having some software system to handle these sorts of internal links might be helpful), but it's certainly got some reasoning behind it.
Okay, you're right about the default settings. He screwed up.
I'm not saying that icons cannot be useful, but I tend to find that the value of them is significantly oversold.
I didn't realize that the links all went to the same "under construction document"...I didn't actually check out what he was doing. Good call.
Javascript is not bad
I'm not saying it doesn't have its use. I just really get annoyed when people use it for regular links (or even to open "preview windows", come to think of it...there's an extension to do that with HTML, IIRC. Usually I think that "preview windows" are a bad idea -- if I want a new window, I'll open a new window or hit the back button).
You're right about the lack of alt text and the fact that it was made with Front Page is a bit funny -- but FrontPage doesn't necessarily generate awful HTML (based on the source of a few websites I've seen), at least if you avoid all its extensions.
I would really like to hear what alternative ideas you have
Oh, lovely. Put me on the spot. Much easier to gripe than fix.
Well...given that I'm a hardcore anti-frames type, I'd probably do things on a page of my own in the traditional HTML style -- if the content isn't too large, on one page with the TOC at the top with links to anchor tags in the text, and if there are a *lot* of poems, links to either "yearly" pages with poems or individual poem pages.
What would probably be more acceptable to you would be simple enlarging the frame containing the Table Of Contents(TOC). If someone has to scroll to read a poem, no great loss. They're more likely to read a poem linearly, and random-access the TOC, and the TOC gets more use, anyway.
my own site a bit more of an artistic toy
The "it's a hobby site" objection is pretty reasonable, and it is undoubtedly the most compatible and usable site of this sort I've used with alternate browsers.
I still think it would be nice to have text somewhere on or near the "expanding image" icons so that one doesn't *have* to flip around with the mouse to find the text.
Thanks for the good conversation!
Get one of the Freenet guys (or, if an EFF guy is willing to help out again, one of them) to point out that Freenet is the *ideal* protection against terrorist attacks on the information infrastructure of the United States.
Consider all the "security" grants that are being thrown left and right at companies. They're lapping up all those tax dollars in the form of goverment contracts. If Freenet can grab just one, that would fund development for a long, long time. Lots of improvements, and I'd have a hard time imagining a more worthy cause than a more robust, secure, attack-resistant, private system that makes for more efficient transfers over the network.
The overwhelming majority of my university's CS research funding comes from the Department of Defense. Freenet couldn't snag just a few of that flood of dollars going to organizations aroudn the country?
So you're from one of the "broad generalization" camps.
:-)
...but broken.
...you'll realize it's all about trade-offs, and speed is secondary to other goals of language design.
Oh, stereotype me, will you.
[snip long passage about how Erlang concurrent programming is good]
Look, I don't have a problem with Erlang as a language. There are, I'm sure, lots of good applications for it. The problem is that I'm looking for a language that focuses on speed, which there is a decided paucity of recently. Despite all the compiler improvements and optimization techniques developed, the fastest choice around is generally *still* C and C++, the first of which is *decades* old, and the second of which has a lot of old baggage.
I want modern functionality with even *better* speed. That's all. Erlang is not what I'm looking for, but that doesn't mean it's not good for some people.
In Java [threads are] an alien invader _bolt-on_ with all the resulting invonveniences and OS-dependence.
I wouldn't call Java's support bolted on. It's language level as well.
Erlang applications scale well with thousands of threads
That's nice (I was quite impressed with CML, which has similar capabilities), but it doesn't really help me unless I'm dead set on writing a program with thousands of preemptive threads.
How fast and how fast for solving which problems
Horizontal market, end user stuff like the desktop programs I mentioned. A web browser. A word processor. A photo manipulation program. A vector graphics program.
Java has been used to write a scalable application framework which has been used to write a web server which scales better than an equivalent C-based server. See http://www.cs.berkeley.edu/~mdw/proj/seda/
Your link (well, what should have been a link) is dead. And scalability is mostly irrelevant. Sun sold lots of copies of Java on the "scalability" argument, but on the level you're talking about, it's not germane to my issues, if I'm writing something for a single node. I can make a scalable system too: T=1000yrs + 1 sec * N, as opposed to T=2 sec * N. Remember, Sun cares about selling hardware, preferably lots of hardware. The biggest draw of their product is that you can "trade up" easily. So they make a slow language that lets you "trade up" easily. And surprise, they push the language. Shocking! Java may be sexy for Sun's target market, true, but not for people like me.
Your broad generalization that Java is slow in any case, any kind of application, anywhere (just because you have this idea in your head), falls flat on its face.
Saying "Java is slow" has some quite obviously understood implications by both you and me, so don't play stupid. That doesn't win any arguments. Java may well be faster at...oh, I don't know, closing. For the vast majority of cases, if I want to sit down and write something that a user interacts with, a Java program is much more sluggish than a C++ program. This is not something that I'm the only one trumpeting -- anyone that's used Java has run into this. And don't give me the "you're using a slow JVM" bullshit that Java advocates love to spout -- I've been developing exclusively with IBM's JDK. There isn't a faster JVM out there for Linux.
"Profile, don't speculate".
Okay. The Java software that I've used is, without exception, sucks down CPU cycles and RAM. Freenet is slow. The theorem-proving environment that Carnegie Mellon University uses for logic courses is slow. Another game-theory environment I've used is slow. Tube (a Java hotline client and library) is mind-bogglingly slow. Now, perhaps I just *happened* to run across every single slow Java application, and just *happened* to run across every single fastest C equivalent, but I don't believe it.
Don't confuse language with a language implementation. If you sacrificed language features to speed -- like it has been done with C, chances are they will never be added to a language later....if a language _implementation_ suffers from performance problems, they can always be dealt with later.
I have macros that both allocate, test for the proper allocation, and typecast the allocation of a struct in C. I use an excellent object-oriented C environment with glib and gtk. I have named constants. The C environment that I use today is far nicer than that three decades ago.
As for your claim that they can always be dealt with later in the implementation, I have an excellent counterexample -- the JVMs that you're so staunchly supporting. When Java was released, it ran like a dog. Sun promised that better compilers would improve things. Optimization got a little better. JITs helped. And you know what? Java is, indeed, faster than it once was. It is *still* sluggish, however. And it's not going to improve much more. And the *language* has limited this -- the lack of typed container objects, the required bounds checking, the almost-impossible-to-avoid reliance on heavy heap-based dynamic allocation of memory. No implementation can fix this. Java as a *language* is terminally limited to never run faster than at a certain clip. Now, it's still quite useful for many things, but not for performance-critical stuff, which happens to matter to me.
Case in point C's string functions are not only ugly...
I'll definitely agree with you there.
And I won't agree with you there.
If language designers wanted to extend the language with new string functions that allocated memory -- how easy of a change would that be?
Really, really easy. Look at glib for C or any one of many, many good string classes for C++.
Premature optimizations in language design, or application design are equally evil.
Are you unbelivably asinine? "Premature optimizations in language design"? How do you think someone is going to "prematurely optimize" a language spec? Do you want to wait until a language is widely used and *then* run out and make lots of changes to it? Heck, that isn't even relevant. I've been talking about existing languages, which are already well understood. There is no prematurity here at all.
And one day, *you* will realize that having a speedy language does not entail *losing* other functionality.
Except your faster language will probably result in more bugs, more time-to-market, more complexity, and more poeople overhead because it wasn't suitable for solving the problem at hand in the first place.
This is coming from the same person that just asked someone not to "generalize" about programming languages. How the hell did you reach the conclusion that speed entailed a lack of safety or an inability to do rapid application development?
Oh. I didn't mean the CMOS clearing jumper -- there are a few motherboards that can revert to a second copy of the BIOS that ships in ROM.
Thank you, though.