Acknowledgement of ignorance as to all of the code in Mozilla -- I just started looking at it three days ago.
It seems like the only place we are different in what we are saying is the matter of completeness: we would both agree that a system library can exist with only one function in it. But how many users would find that library helpful? My point was that a complete system library isn't as easy as the questioner might have thought.
Counterpoints/Questions: to say LiveWire/SSJS (SERVER SIDE JAVA SCRIPT) is not part of the language seems to be a little disingenuous. Most JS books at least deal with it, and a lot of heavy duty SSJS coding is taking place.
You mentioned LiveConnect. I am speaking from a little bit of ignorance here, but until the ElectricFire (check it out on Mozilla, people!) code is operational,the JavaScript hooks are to non-OSS code, right?
Thanks for the replies. I will be looking at the SRPMS and the sample app later. Could you give us an URL/URLs to where JS sits in the Mozilla distribution?
Hey, no big surprise, an anonmymous coward attacks my intelligence! and thinks that I didn't understand the post I was responding to. Wrong!!
Well, AC, let me use my "minute level of comprehension" to explain it to you. Maybe you'll get it, maybe not. I'll try to make it easy...
Would you rather have the world dump it's garbage on your front door, and empty it yourself, or hire someone else to prevent the garbage from landing there in the first place?
Because the language is still evolving, not as easy as we might hope. Additionally, Javascript has hooks to Jave, which is also still evolving. On the server (LiveWire), platforms continue to gain functionality that LiveWire is supposed to be able to take advantage of.
So, we are talking about a many headed development effort here. However, I do believe that any coders working on an OSS JavaScript Interpreter would do well to keep the development of a standard system library near the top of their design priority list
I have been studying wavelet compression for a number of years now.
It has been well proven that well coded wavelet transforms can be made to be more accurate than the DCT (Discrete Cosine Transforms) that are at the heart of both the JPEG and GIF formats.
The problem is, most of these formats are still at the academic stage of coding, have been licensed into extinction, and in general, don't offer the rest of the world much of a reason to come on board.
After spending a few minutes perusing the Summus Website and their technology, only one item struck me as being worthwhile -- the idea of focus regions, i.e., areas where less compression can be used to maintain higher fidelity to the original image.
Two things I would like to see:
1. this regioning technique incorporated into PNG, JPEG, etc. 2. a fast, Open Source wavelet transform which all of us Linux coders can put through the grinder until it is as worthwhile as JPEG and GIF.
I am willing to put up the server space for an OSS wavelet project if enough/.'ers are interested.
Feel free to send an inquiry, but make sure you indicate both your coding and wavelet experience in the body of the e-mail; items without both will simply be trashed.
I am probably going to get flamed for this, and to be frank I don't care.
If Slashdot was not censored to some degree, many of us would not bother to read the pages. If there were not writers like Jon Katz associated with Slashdot, we would not return here as often. I am sick of "windbag" comments -- at least Jon Katz is tuned into the same issues that most Slashdot'rs are. Not only that, Jon returns e-mail and even reads our comments. So in a way, his voice reflects a little bit of our voices to him.
Rob, keep up the good work. Jon, keep up the good work.
Flamers who have nothing better to do than take pot shots at one of the "good guys" should think about keeping a new habit.
Unfortunately, I don't have any useful numbers for people to play with/banter around. My response here is more about usefulness.
In the dark ages before PC enlightenment -- i.e., machines the masses could afford to own themselves -- the mainframes and minicomputers were handling 40-100 terminals, batch jobs, etc. I remember a professor of mine complaining how the cost of CPU time could be quantitively valued in DOLLARS per MICROSECOND.
A batch project run in 1980 using a high end 1977 IBM 370 (with all other users locked out) involving about 100 megabytes of data (cross referencing text, etc.) took about three days to run. Interestingly, the IS department who generally operated the machine expected the data run to take TWO WEEKS.
I can compile a 10M C++ code library from scatch on my K6/266 equipped machine including all of the added error checking required for code compilation, linking, etc. in about 15 minutes. I would suspect that other PC developers have larger projects which have been compiled even faster.
If all of the other mathematical elements were held constant, this would mean that my K6/266 would have taken about 2-1/2 hrs. to process the 1980 text run, about 40X faster than the high end 370.
Because I built it (last year), my total cost of components not counting the monitor, which I already owned) was about $580.
The system 370 cost about $3,000,000.
Funny thing. The K6 is idle about 75% of the time now and will be retired later this year; the 370 wasn't fully retired until around 1991.
Let me chime in here. Most of the comments and virtually all of the report seems to miss a major point of why a corporation would want to install Linux in the first place.
That point is that with Linux, control of system support returns to the company, versus the hand wringing that goes on with every little burp and twitch of WinNT.
All of the big hitters (Gartner, Ernst & Young, Anderson Consulting, etc. downplay Linux because of the lack of "corporate support."
The buggy nature of virtually every early version of Microsoft OS and development system have allowed many of the major consulting firms to leach major bucks out of the big companies with trainees just out of college but that sound like they really understand Microsoft's wares.
Which doesn't even count the major bucks which alot of VARS or former VARS like me paid to Microsoft for support subscriptions that proved essentially worthless because the low quality of the support staff at MS. Usually by the time MS support came up with the answer, I had discovered it myself, or dumped the product.
Consider that for the same cost of all the client OS charges and support contracts currently paid out to MS and consulting organizations to individiuals who JUST SUPPORT MS OS's (not counting development) any major corporation could hire 5-10 true Linux wizards, arrange them in a "think tank" type workgroup, and have superior systems level support. One criticism of this concept which I have heard put out by a consulting company is what if one of the "gurus" leaves? Hire another highly qualified Linux person to keep the team functioning. Versus the consulting companies who constantly ship new people in and out.
I challenge Gartner or anyone else prove that the cost of supporting Linux in house is higher than what Microsoft and minions are currently milking the Fortune 1000 for.
To be honest 'though, I'm lucky. I work in a mostly Microsoft free shop.
It's enough to make you store your spare server in an underground vault! What? no spare servers?
Seriously though. Much of the major bandwidth which carries the Internet is effectively shielded because it is carried in underground fiber optics and cables, and are generally immune to RF, except in the computers at the terminations. Many of these are also underground and isolated just for that reason -- a solar storm puts out enough stray frequecies to mess up communications on occasion if they don't.
EMP is a much greater danger to the global economy than single strike weapons, because it has the capacity to down all of our machines at the same time. A "single strike" RF weapon such as shown to 20/20 would be much more of a terrorist weapon, because it's ability is limited to causing local damage.
What would be a more interesting story is how a community/organization/etc. could protect themselves against such weapons.
>>Basically, I don't believe Open Source will produce polished GUI applications...
I disagree. Although I haven't released yet I and many others have too much pride in our work to leave something "unpolished." Coupled with the fact that the Linux User community is the fastest bug reporting crew I've ever seen, OpenSource Software should be MORE polished than the competition.
> Instead, you'll get more retrofitted bloatware (GtkEmacs, anyone?) and lots of pointless cloning (57 different IRC clients, anyone?).
True, but look at Windows. Their are probably fifty different Word Processors you can buy. But only the top four or five really matter, because their features are polished to the point of survival in a tough market.
Same for Linux if not more so. What I look forward to is a code library that allows me to point my compiler to a target desktop (KDE, GNOME, or TheNextNewGreatestVersion, whatever it is) and be able to release versions of my application without completely rebuilding the components from scratch for each desktop.
I grew up in LV and something you need to realize about UNLV's computer science department.
Historically it has been very conservative, as the major market in LV was the defense industries. As far as a user's group, I can guarantee that if you have an operating Linux system and you post on campus, within a few days you will generate enough interest to either find or start your own.
Half and Half: let me offer a couple of C++ programmer perspectives.
There are numerous projects currently being worked on by OpenSource programmers to port languages and databases such as Clipper, dBase, etc. to the Linux world. These were good DOS based tools which for the most part did not survive the migration into Windows very well, mainly because ODBC, Visual Basic, and Access, etc. made it too damn easy to kludge together small databases, etc. and killed alot of the midrange market for development tools)
That being said, in the Linux world, not counting the Oracles, etc. which are currently porting their products, there are already plenty of fairly powerful databases available such as MySQL, etc. which will also continue to improve.
What we do not have yet is a GUI based development environment in Linux which is as flexible and powerful as the MS, Symantec, Inprise (Borland), and Sybase tool sets.
Stay tuned. It is only a matter of time before the tools develop, whether OpenSourced or by the professional tool sellers such as Symantec.
Once we have effective, easy to use development tools, foundation class libraries, etc., the powerful GUI applications will come, because the market is there.
Slashdot Mirror
Well and good.
/'ers report on the KAI compiler's performance?
For the 'x86 chips, I like the Cygnus tools well enough, but what about the *rest* of the world, also known as Linux PPC, G3/G4, SA-110, etc.?
Secondarily, can any
I know it's not freeware, but their compiler is the only one I know of that has benchmarked C++ code running competitively with Fortran.
Agreement with much of what you said.
Acknowledgement of ignorance as to all of the code in Mozilla -- I just started looking at it three days ago.
It seems like the only place we are different in what we are saying is the matter of completeness: we would both agree that a system library can exist with only one function in it. But how many users would find that library helpful? My point was that a complete system library isn't as easy as the questioner might have thought.
Counterpoints/Questions: to say LiveWire/SSJS (SERVER SIDE JAVA SCRIPT) is not part of the language seems to be a little disingenuous. Most JS books at least deal with it, and a lot of heavy duty SSJS coding is taking place.
You mentioned LiveConnect. I am speaking from a little bit of ignorance here, but until the ElectricFire (check it out on Mozilla, people!) code is operational,the JavaScript hooks are to non-OSS code, right?
Thanks for the replies. I will be looking at the SRPMS and the sample app later. Could you give us an URL/URLs to where JS sits in the Mozilla distribution?
Hey, no big surprise, an anonmymous coward attacks my intelligence! and thinks that I didn't understand the post I was responding to. Wrong!!
Well, AC, let me use my "minute level of comprehension" to explain it to you. Maybe you'll get it, maybe not. I'll try to make it easy...
Would you rather have the world dump it's garbage on your front door, and empty it yourself, or hire someone else to prevent the garbage from landing there in the first place?
Java, not Jave. Etc. Missed the preview button again. Flame not, okay? :^)
Because the language is still evolving, not as easy as we might hope. Additionally, Javascript has hooks to Jave, which is also still evolving. On the server (LiveWire), platforms continue to gain functionality that LiveWire is supposed to be able to take advantage of.
So, we are talking about a many headed development effort here. However, I do believe that any coders working on an OSS JavaScript Interpreter would do well to keep the development of a standard system library near the top of their design priority list
Unfortunately, you forgot to include the URL for the Analog Devices site, specifically related to the adv6XX chips.
Here 'tis:
http://www.analog.com/techsupt/software/lcm.zip
I have been studying wavelet compression for a number of years now.
/.'ers are interested.
It has been well proven that well coded wavelet transforms can be made to be more accurate than the DCT (Discrete Cosine Transforms) that are at the heart of both the JPEG and GIF formats.
The problem is, most of these formats are still at the academic stage of coding, have been licensed into extinction, and in general, don't offer the rest of the world much of a reason to come on board.
After spending a few minutes perusing the Summus Website and their technology, only one item struck me as being worthwhile -- the idea of focus regions, i.e., areas where less compression can be used to maintain higher fidelity to the original image.
Two things I would like to see:
1. this regioning technique incorporated into PNG, JPEG, etc.
2. a fast, Open Source wavelet transform which all of us Linux coders can put through the grinder until it is as worthwhile as JPEG and GIF.
I am willing to put up the server space for an OSS wavelet project if enough
Feel free to send an inquiry, but make sure you indicate both your coding and wavelet experience in the body of the e-mail; items without both will simply be trashed.
I am probably going to get flamed for this, and to be frank I don't care.
If Slashdot was not censored to some degree, many of us would not bother to read the pages. If there were not writers like Jon Katz associated with Slashdot, we would not return here as often. I am sick of "windbag" comments -- at least Jon Katz is tuned into the same issues that most Slashdot'rs are. Not only that, Jon returns e-mail and even reads our comments. So in a way, his voice reflects a little bit of our voices to him.
Rob, keep up the good work.
Jon, keep up the good work.
Flamers who have nothing better to do than take pot shots at one of the "good guys" should think about keeping a new habit.
Shut the hell up.
Unfortunately, I don't have any useful numbers for people to play with/banter around. My response here is more about usefulness.
In the dark ages before PC enlightenment -- i.e., machines the masses could afford to own themselves -- the mainframes and minicomputers were handling 40-100 terminals, batch jobs, etc. I remember a professor of mine complaining how the cost of CPU time could be quantitively valued in DOLLARS per MICROSECOND.
A batch project run in 1980 using a high end 1977 IBM 370 (with all other users locked out) involving about 100 megabytes of data (cross referencing text, etc.) took about three days to run. Interestingly, the IS department who generally operated the machine expected the data run to take TWO WEEKS.
I can compile a 10M C++ code library from scatch on my K6/266 equipped machine including all of the added error checking required for code compilation, linking, etc. in about 15 minutes. I would suspect that other PC developers have larger projects which have been compiled even faster.
If all of the other mathematical elements were held constant, this would mean that my K6/266 would have taken about 2-1/2 hrs. to process the 1980 text run, about 40X faster than the high end 370.
Because I built it (last year), my total cost of components not counting the monitor, which I already owned) was about $580.
The system 370 cost about $3,000,000.
Funny thing. The K6 is idle about 75% of the time now and will be retired later this year; the 370 wasn't fully retired until around 1991.
My how things change...
Let me chime in here. Most of the comments and virtually all of the report seems to miss a major point of why a corporation would want to install Linux in the first place.
That point is that with Linux, control of system support returns to the company, versus the hand wringing that goes on with every little burp and twitch of WinNT.
All of the big hitters (Gartner, Ernst & Young, Anderson Consulting, etc. downplay Linux because of the lack of "corporate support."
The buggy nature of virtually every early version of Microsoft OS and development system have allowed many of the major consulting firms to leach major bucks out of the big companies with trainees just out of college but that sound like they really understand Microsoft's wares.
Which doesn't even count the major bucks which alot of VARS or former VARS like me paid to Microsoft for support subscriptions that proved essentially worthless because the low quality of the support staff at MS. Usually by the time MS support came up with the answer, I had discovered it myself, or dumped the product.
Consider that for the same cost of all the client OS charges and support contracts currently paid out to MS and consulting organizations to individiuals who JUST SUPPORT MS OS's (not counting development) any major corporation could hire 5-10 true Linux wizards, arrange them in a "think tank" type workgroup, and have superior systems level support. One criticism of this concept which I have heard put out by a consulting company is what if one of the "gurus" leaves? Hire another highly qualified Linux person to keep the team functioning. Versus the consulting companies who constantly ship new people in and out.
I challenge Gartner or anyone else prove that the cost of supporting Linux in house is higher than what Microsoft and minions are currently milking the Fortune 1000 for.
To be honest 'though, I'm lucky. I work in a mostly Microsoft free shop.
It's enough to make you store your spare server in an underground vault! What? no spare servers?
Seriously though. Much of the major bandwidth which carries the Internet is effectively shielded because it is carried in underground fiber optics and cables, and are generally immune to RF, except in the computers at the terminations. Many of these are also underground and isolated just for that reason -- a solar storm puts out enough stray frequecies to mess up communications on occasion if they don't.
EMP is a much greater danger to the global economy than single strike weapons, because it has the capacity to down all of our machines at the same time. A "single strike" RF weapon such as shown to 20/20 would be much more of a terrorist weapon, because it's ability is limited to causing local damage.
What would be a more interesting story is how a community/organization/etc. could protect themselves against such weapons.
This is one of the best anti-FUD articles I have ever read. CmdrTaco -- Sign this guy up!!
>>Basically, I don't believe Open Source will produce polished GUI applications...
I disagree. Although I haven't released yet I and many others have too much pride in our work to leave something "unpolished." Coupled with the fact that the Linux User community is the fastest bug reporting crew I've ever seen, OpenSource Software should be MORE polished than the competition.
> Instead, you'll get more retrofitted bloatware (GtkEmacs, anyone?) and lots of pointless cloning (57 different IRC clients, anyone?).
True, but look at Windows. Their are probably fifty different Word Processors you can buy. But only the top four or five really matter, because their features are polished to the point of survival in a tough market.
Same for Linux if not more so. What I look forward to is a code library that allows me to point my compiler to a target desktop (KDE, GNOME, or TheNextNewGreatestVersion, whatever it is) and be able to release versions of my application without completely rebuilding the components from scratch for each desktop.
Suggestions anyone?
I grew up in LV and something you need to realize about UNLV's computer science department.
Historically it has been very conservative, as the major market in LV was the defense industries. As far as a user's group, I can guarantee that if you have an operating Linux system and you post on campus, within a few days you will generate enough interest to either find or start your own.
Half and Half: let me offer a couple of C++ programmer perspectives.
There are numerous projects currently being worked on by OpenSource programmers to port languages and databases such as Clipper, dBase, etc. to the Linux world. These were good DOS based tools which for the most part did not survive the migration into Windows very well, mainly because ODBC, Visual Basic, and Access, etc. made it too damn easy to kludge together small databases, etc. and killed alot of the midrange market for development tools)
That being said, in the Linux world, not counting the Oracles, etc. which are currently porting their products, there are already plenty of fairly powerful databases available such as MySQL, etc. which will also continue to improve.
What we do not have yet is a GUI based development environment in Linux which is as flexible and powerful as the MS, Symantec, Inprise (Borland), and Sybase tool sets.
Stay tuned. It is only a matter of time before the tools develop, whether OpenSourced or by the professional tool sellers such as Symantec.
Once we have effective, easy to use development tools, foundation class libraries, etc., the powerful GUI applications will come, because the market is there.
So don't despair: join the effort.