In fact, this sounds interesting. The thing is, it has already been reported by news.dir.bg (not that this makes it more credible or anything, but still...), so mod this one up if you feel like it.
I agree about the 6800:)
I just didn't like the reviews of 5600's and 5700's.
I think the 5900 XT is the way to go for now (not very expensive, good performance), but maybe I'll have to stay with my 4200 for now:(
Although once the 6800's are out for a bit, it'll drop to the ultra-cheap category.
[/quote]
Isn't that cute... But it's WRONG! Have you seen the prices of GF3 come down to the ultra-cheap category? Instead, these cards just disappeared. Have you seen the prices of GF4 Ti come down as well? Neither have I.
The way I see it, nowadays there are several different types of cards : Cheap (GF4 MX, GF FX 5200), Medium (GF FX 5600, GF4 Ti 4200), High (GF FX 5700, GF FX 5900 XT), Impossible (GF FX 5900, GF FX 6800).
Cheap - good for nothing. Medium - OK but slow. High - too expensive to buy or too slow for their price. Impossible - for marketing purposes only.
A card may drop its price, but _never_ goes down as much as falling into the Cheap category. It silently disappears when it reaches the Meduim level (and sometimes even before that) to be replaces by a slower but higher - numbered brand-new overpriced stuff (think : GF4 Ti 4200 vs GF FX 5600).
I think I have noticed the same strategy in Intel's behaviour : Several months back a Pentium 3 at 1 Ghz was more expensive than a Celeron at 2 Ghz (I know, P4 with no cache is good for nothing, but come ooooon!).
Ah, the good old times of GF 2 were great - then the cards *did* get cheaper with time... And the "faster" video cards were indeed faster. And the "faster" CPUs were indeed faster. Now, it's all just marketing tricks.
At work, I have a P4 at 2.4 ghz, 512 mb RAM, 1024 mb swap partition for Linux, GeForce 4 Ti 4200, Original NVidia drivers for Linux, Mandrake 10 C.Edition, Sun JDK 1.4.2_03 for Linux, Windows 2000, Sun JDK 1.4.2_03 for Windows.
I found that native KDE apps render _much_ slower than ProSyst's Java IDE - mBedded Builder, written entirely in Java, using AWT (PGUI - ProsystGUI on top of AWT). Also, Eclipse seemed slower (with its native GUI), not to mention KDevelop.
On Windows 2000, however, the mBB is still visually slow, espacially when compared to native apps and Eclipse.
So, I think, for Linux/X at least, Java _is_ fast enough already!
If you combine that with a plugin-in system like OSGI (IBM will be using OSGI in the next generation of Eclipse, I heard rumors) that allows for dynamic updates of portions of the code (bundles), you get the idea.
Go, JIT Languages!
BTW, JIT Langs are faster at times - the code is compiled at runtime and can thus be optimized for whatever hardware you are using - and complied code is discarded at exit (or saved for later runs, I heard rumors that JDK 1.5 will be doing exactly that)
If the JVM and the major libs are loaded only at startup (hint : OSGI), then Java becomes good for the desktop - almost zero startup time, fluent painting (like a crazy 100+ frames per sec game), etc - slick and cool.
Just make sure you deal with the ghasty mem leaks of AWT first - sometimes the GC seems unable to clean AWT objects once they are created, because AWT keeps them in some threads for who knows what.
Season's Greetings, Legally Revised
on
What You Can't Say
·
· Score: 3, Funny
Please accept with no obligation, implied or implicit, my best wishes for an environmentally conscious, socially responsible, low-stress, non-addictive, gender-neutral celebration of the winter solstice holiday, practiced within the most enjoyable traditions of the religious persuasion of your choice, or secular practices of your choice, with respect for the religious/secular persuasions and/or traditions of others, or their choice not to practice religious or secular traditions at all...
And a fiscally successful, personally fulfilling, and medically uncomplicated recognition of the onset of the generally accepted calendar year 2004, but not without due respect for the calendars of choice of other cultures whose contributions to society have helped make America great (not to imply that America is necessarily greater than any other country or is the only "America" in the Western hemisphere), and without regard to the race, creed, color, age, physical ability, religious faith, or sexual orientation of the wishee.
This wish is limited to the customary and usual good tidings for a period of one year, or until the issuance of a subsequent holiday greeting, whichever comes first. "Holiday" is not intended to, nor shall it be considered, limited to the usual Judeo-Christian celebrations or observances, or to such activities of any organized or ad hoc religious community, group, individual, or belief (or lack thereof).
Note: By accepting this greeting, you are accepting these terms. This greeting is subject to clarification or withdrawal and is revocable at the sole discretion of the wisher at any time, for any reason or for no reason at all. This greeting is freely transferable with no alteration to the original greeting. This greeting implies no promise by the wisher to actually implement any of the wishes for the wishee her/himself or others, or responsibility for the consequences which may arise from the implementation or non-implementation of same. This greeting is void where prohibited by law.
You must *NOT* rely on filanizers to do the clean-up. That is a bad Java practice. You should use try-finally blocks for that: InputStream fileIn = new FileInputStream("test.txt"); try { in = new BufferedInputStream(fileIn, 1024 * 8); doSomeReading(in); } finally { fileIn.close(); } Otherwise yes, I agree typecasts are a nuisance and that probably it is better to use a compiler that adds them for you. But adding generics on a VM level would break the compatibility with 1.1.8 on which many small embedded devices rely today.
1. Establish a huge server with free (not rms-free, but beer-free) online songs. Have them in lossless formats, so audiophiles will be pleased. Let anyone download it and spread it around, but incorporate drm (i.e. something palladian) which reports votes from the users' computers when the title is being played for the first time. Make it possible to record the songs as files, not as audio cds. This helps preserve the quality for the generations, and keeps the voter drm in.
2. Establish another huge server where all the votes go. Make the results public. This makes everyone happy.
3. See the results from 2. Make assumptions in which area of the country which group is most popular. Then, make a concert there. Do that each month in each region of the country.
4. Profit. Not from selling super-expensive cd-s at 100x their normal price, but from taking the artists to their public, in flesh. Everyone is happy.
But of course, it is much better to have the artists sign a rights waiver for a few pennies, then stick them into a studio for a few hours, then profit for years on end by selling quickly deteriorating cds at inflated prices.
But then again, please, consider my words? I am serious. This has been done before the era of the recordable performances, I think it is possible to do it again.
I think Java is good. It fails at some points (this is by a person with 3+ years of professional Java experience): 1) No convenient way to call methods by name. Takes quite a few try-catch constructs, etc. What about this snippet: Object x =... call someMethod(a, b, c, d) at x; or something. Ok, it may throw any necessary exceptions. 2) No standard way to access DBs. JDBC is a pain. It works, but with lots of workarounds for different dbs. One must implement class loaders, selecting the driver at runtime is terrible, parsing the CREATE statements to replace the data types is way out of bounds. 3) Terrible with memory management, especially the GUI stuff. There just HAS to be some efficient way to deal with this. Maybe mix GC with ref count + explicit delete statement, which zeros all references to the object (possible with the current Sun JVM implementation, because the references are one step further). 4) No way collect a few threads, name them an "application", then kill them off. Oh, there is, but you have to worry about bizarre deadlocks resulting from unsent notifications, etc. 5) The localization is a PAIN. You must write properties files, compare locales, etc. i.e. do all the work by hand. And there is always the temptation to hardcode a string in a hurry. 6) Nothing really to force you to avoid deadlocks. Some ideas : throw exceptions when deadlock is reached, etc.
I love the idea of OSGI (my company, ProSyst, is a lead vendor of the OSGI framework). The idea is simple : jar files, called bundles, export and import packages, and register services (objects implementing interfaces both the user and the exporter have access to). Problems : no way to completely kill off (safely) any threads the bundle might have started when it is uninstalled.
Some suggestions about the new language:
1) Add call-by-name. 2) DB support. I saw one message before this one which was very well thought out, and was on this subject. 3) Add ref counts and explicit delete-s to the GC 4) Borrow ideas from OSGI - easy plugins, services, etc. Runtime load/unload of components. Runtime SAFE kill-off of entire bundles. Kill their threads, close their files, free their memory. This is done (sort of - the memory freeing comes to mind) with win32 dlls, but no way to do it in Java 5) Add localization support. For example, some library class which loads the appropriate string tables according to the locale (the easiest solution) 6) Two ideas here : 1) force the monitor objects to be declared beforehand, and assign priorities. If someone tries to lock these objects out-of-order, throw exceptions. 2) throw exceptions when a deadlock is reached.
more things to think about: - realtime support. Threads which cannot allocate memory, and can only use static memory. - good cross-platform gui. Swing is a great idea, I mean its programming interface, no the terrible self dead-locking, ugly implementation. Having platform-dependent look and feel (I *mean* native look and feel, not some "lightweight" blown-out implementation, which slows down to a crawl at the simplest operations). See previous thoughts about deadlocks.
And about templates : I do not care, really (oh, the horror). Typecasts are not a problem, when you only have one or two types of objects in the same collection. I even prefer there not to be such.
Now, about the platform: How about have the language compile to C or Java (make it an option). Then, make an option to disable the garbage collector (impossible for Java, but a valid options for C). If you compile to C, make sure you use a serious GC, not a conservative one which treats all your data as pointers. Use a Java-like type system. This can even compile to.NET if necessary. Thus, you can target 3 platforms with an ease.
Slashdot Mirror
In fact, this sounds interesting. The thing is, it has already been reported by news.dir.bg (not that this makes it more credible or anything, but still...), so mod this one up if you feel like it.
Mod this up!
Mod This Up!
Have a look at this thing:
QT3 Win32
I haven't used it, however.
I agree about the 6800 :)
I just didn't like the reviews of 5600's and 5700's.
I think the 5900 XT is the way to go for now (not very expensive, good performance), but maybe I'll have to stay with my 4200 for now :(
[quote]
Although once the 6800's are out for a bit, it'll drop to the ultra-cheap category.
[/quote]
Isn't that cute... But it's WRONG! Have you seen the prices of GF3 come down to the ultra-cheap category? Instead, these cards just disappeared. Have you seen the prices of GF4 Ti come down as well? Neither have I.
The way I see it, nowadays there are several different types of cards : Cheap (GF4 MX, GF FX 5200), Medium (GF FX 5600, GF4 Ti 4200), High (GF FX 5700, GF FX 5900 XT), Impossible (GF FX 5900, GF FX 6800).
Cheap - good for nothing.
Medium - OK but slow.
High - too expensive to buy or too slow for their price.
Impossible - for marketing purposes only.
A card may drop its price, but _never_ goes down as much as falling into the Cheap category. It silently disappears when it reaches the Meduim level (and sometimes even before that) to be replaces by a slower but higher - numbered brand-new overpriced stuff (think : GF4 Ti 4200 vs GF FX 5600).
I think I have noticed the same strategy in Intel's behaviour : Several months back a Pentium 3 at 1 Ghz was more expensive than a Celeron at 2 Ghz (I know, P4 with no cache is good for nothing, but come ooooon!).
Ah, the good old times of GF 2 were great - then the cards *did* get cheaper with time... And the "faster" video cards were indeed faster. And the "faster" CPUs were indeed faster. Now, it's all just marketing tricks.
At work, I have a P4 at 2.4 ghz, 512 mb RAM, 1024 mb swap partition for Linux, GeForce 4 Ti 4200, Original NVidia drivers for Linux, Mandrake 10 C.Edition, Sun JDK 1.4.2_03 for Linux, Windows 2000, Sun JDK 1.4.2_03 for Windows.
I found that native KDE apps render _much_ slower than ProSyst's Java IDE - mBedded Builder, written entirely in Java, using AWT (PGUI - ProsystGUI on top of AWT). Also, Eclipse seemed slower (with its native GUI), not to mention KDevelop.
On Windows 2000, however, the mBB is still visually slow, espacially when compared to native apps and Eclipse.
So, I think, for Linux/X at least, Java _is_ fast enough already!
If you combine that with a plugin-in system like OSGI (IBM will be using OSGI in the next generation of Eclipse, I heard rumors) that allows for dynamic updates of portions of the code (bundles), you get the idea.
Go, JIT Languages!
BTW, JIT Langs are faster at times - the code is compiled at runtime and can thus be optimized for whatever hardware you are using - and complied code is discarded at exit (or saved for later runs, I heard rumors that JDK 1.5 will be doing exactly that)
If the JVM and the major libs are loaded only at startup (hint : OSGI), then Java becomes good for the desktop - almost zero startup time, fluent painting (like a crazy 100+ frames per sec game), etc - slick and cool.
Just make sure you deal with the ghasty mem leaks of AWT first - sometimes the GC seems unable to clean AWT objects once they are created, because AWT keeps them in some threads for who knows what.
Please accept with no obligation, implied or implicit, my best wishes for an environmentally conscious, socially responsible, low-stress, non-addictive, gender-neutral celebration of the winter solstice holiday, practiced within the most enjoyable traditions of the religious persuasion of your choice, or secular practices of your choice, with respect for the religious/secular persuasions and/or traditions of others, or their choice not to practice religious or secular traditions at all...
And a fiscally successful, personally fulfilling, and medically uncomplicated recognition of the onset of the generally accepted calendar year 2004, but not without due respect for the calendars of choice of other cultures whose contributions to society have helped make America great (not to imply that America is necessarily greater than any other country or is the only "America" in the Western hemisphere), and without regard to the race, creed, color, age, physical ability, religious faith, or sexual orientation of the wishee.
This wish is limited to the customary and usual good tidings for a period of one year, or until the issuance of a subsequent holiday greeting, whichever comes first. "Holiday" is not intended to, nor shall it be considered, limited to the usual Judeo-Christian celebrations or observances, or to such activities of any organized or ad hoc religious community, group, individual, or belief (or lack thereof).
Note: By accepting this greeting, you are accepting these terms. This greeting is subject to clarification or withdrawal and is revocable at the sole discretion of the wisher at any time, for any reason or for no reason at all. This greeting is freely transferable with no alteration to the original greeting. This greeting implies no promise by the wisher to actually implement any of the wishes for the wishee her/himself or others, or responsibility for the consequences which may arise from the implementation or non-implementation of same. This greeting is void where prohibited by law.
Mod this up!
You must *NOT* rely on filanizers to do the clean-up. That is a bad Java practice. You should use try-finally blocks for that:
InputStream fileIn = new FileInputStream("test.txt");
try {
in = new BufferedInputStream(fileIn, 1024 * 8);
doSomeReading(in);
} finally {
fileIn.close();
}
Otherwise yes, I agree typecasts are a nuisance and that probably it is better to use a compiler that adds them for you. But adding generics on a VM level would break the compatibility with 1.1.8 on which many small embedded devices rely today.
I was thinking of something that goes like this:
1. Establish a huge server with free (not rms-free, but beer-free) online songs. Have them in lossless formats, so audiophiles will be pleased. Let anyone download it and spread it around, but incorporate drm (i.e. something palladian) which reports votes from the users' computers when the title is being played for the first time. Make it possible to record the songs as files, not as audio cds. This helps preserve the quality for the generations, and keeps the voter drm in.
2. Establish another huge server where all the votes go. Make the results public. This makes everyone happy.
3. See the results from 2. Make assumptions in which area of the country which group is most popular. Then, make a concert there. Do that each month in each region of the country.
4. Profit. Not from selling super-expensive cd-s at 100x their normal price, but from taking the artists to their public, in flesh. Everyone is happy.
But of course, it is much better to have the artists sign a rights waiver for a few pennies, then stick them into a studio for a few hours, then profit for years on end by selling quickly deteriorating cds at inflated prices.
But then again, please, consider my words? I am serious. This has been done before the era of the recordable performances, I think it is possible to do it again.
I think Java is good. It fails at some points (this is by a person with 3+ years of professional Java experience): ...
.NET if necessary. Thus, you can target 3 platforms with an ease.
1) No convenient way to call methods by name. Takes quite a few try-catch constructs, etc. What about this snippet:
Object x =
call someMethod(a, b, c, d) at x;
or something. Ok, it may throw any necessary exceptions.
2) No standard way to access DBs. JDBC is a pain. It works, but with lots of workarounds for different dbs. One must implement class loaders, selecting the driver at runtime is terrible, parsing the CREATE statements to replace the data types is way out of bounds.
3) Terrible with memory management, especially the GUI stuff. There just HAS to be some efficient way to deal with this. Maybe mix GC with ref count + explicit delete statement, which zeros all references to the object (possible with the current Sun JVM implementation, because the references are one step further).
4) No way collect a few threads, name them an "application", then kill them off. Oh, there is, but you have to worry about bizarre deadlocks resulting from unsent notifications, etc.
5) The localization is a PAIN. You must write properties files, compare locales, etc. i.e. do all the work by hand. And there is always the temptation to hardcode a string in a hurry.
6) Nothing really to force you to avoid deadlocks. Some ideas : throw exceptions when deadlock is reached, etc.
I love the idea of OSGI (my company, ProSyst, is a lead vendor of the OSGI framework). The idea is simple : jar files, called bundles, export and import packages, and register services (objects implementing interfaces both the user and the exporter have access to). Problems : no way to completely kill off (safely) any threads the bundle might have started when it is uninstalled.
Some suggestions about the new language:
1) Add call-by-name.
2) DB support. I saw one message before this one which was very well thought out, and was on this subject.
3) Add ref counts and explicit delete-s to the GC
4) Borrow ideas from OSGI - easy plugins, services, etc. Runtime load/unload of components. Runtime SAFE kill-off of entire bundles. Kill their threads, close their files, free their memory. This is done (sort of - the memory freeing comes to mind) with win32 dlls, but no way to do it in Java
5) Add localization support. For example, some library class which loads the appropriate string tables according to the locale (the easiest solution)
6) Two ideas here : 1) force the monitor objects to be declared beforehand, and assign priorities. If someone tries to lock these objects out-of-order, throw exceptions. 2) throw exceptions when a deadlock is reached.
more things to think about:
- realtime support. Threads which cannot allocate memory, and can only use static memory.
- good cross-platform gui. Swing is a great idea, I mean its programming interface, no the terrible self dead-locking, ugly implementation. Having platform-dependent look and feel (I *mean* native look and feel, not some "lightweight" blown-out implementation, which slows down to a crawl at the simplest operations). See previous thoughts about deadlocks.
And about templates : I do not care, really (oh, the horror). Typecasts are not a problem, when you only have one or two types of objects in the same collection. I even prefer there not to be such.
Now, about the platform:
How about have the language compile to C or Java (make it an option). Then, make an option to disable the garbage collector (impossible for Java, but a valid options for C). If you compile to C, make sure you use a serious GC, not a conservative one which treats all your data as pointers. Use a Java-like type system. This can even compile to
-- bailing out.