I think they're only focusing on persisting some object state, not replacing databases. Object persistence in a RDBMS is usually done with BLOBs or O/R mapping (putting the state data into tables). OODBMSes have not been very successful the enterprise market.
Discussing the enterprise market is another topic, so I will only discuss this from a technology aspect below.
Persisting objects to RAM is not a new idea. Gemstone made a business out of their persistent cache software for Smalltalk and later Java. There are several researchers looking at reliable distributed data structures like Ninja at Berkeley.
The new idea here seems to be the logging mechanism using the command pattern. It's a big performance boost for writing reliably because you don't have to transactionally synchronize the entire object state to disk, only the changes.
You are right that people like their databases and this doesn't deal with querying, large datasets, and other real world issues.
I used to think the same thing about bloat and used FVWM/WindowMaker/whatever, but I've had fewer headaches since switching to KDE a few years ago. I admit some KDE stuff is a bit dorky, but overall it is very well done.
You're better off doing GUIs in a way people are familiar with. The familiar has become intuitive. When you change it, you are just making the computer get in the way. Those are common human factors / usability ideas.
Why do you think you can do a better GUI and make better widgets? You probably can't. Why do I have all these Linux apps with their own widgets and UI paradigm that work poorly? There is no good reason.
People don't want your avant garde hyperdimensional pie menu and mp3 visualizer scrollbar thingy, they just want to be able to use an app instead of fighting it.
I agree. This is not a good system for millions of documents. It's proportional to #terms * #documents, which obviously won't scale. The simple vector space model is fundamentally flawed for ranking in that it is biased towards returning short documents containing your terms. I still think this was a good article though.
Since MSN Messenger is for windows, that would explain the Windows requirement
Most IM systems are OS agnostic. Do you think MS will publish their protocol?
Finally the P2P update. Well that makes sense really.
It only makes sense when everything is "part of the operating system," i.e. it doesn't make sense since this P2P stuff is used only for three degrees. It may be a good idea to have a P2P OS service in the long run, but P2P protocols really haven't standardized. IIRC Clay Shirky had a good article about lack of standardization being a good thing right now.
Requires Linux 2.5.62 with KDE 3.0 and peer-to-peer upgrade.
(with the subtitling that it doesn't run on windows)
Would someone have made exactly the same comment?
No, because in all likelihood the Linux app would be open source and not subject to all this proprietary vendor lock in bullshit that MS is famous for.
Viruses and Virii both are acceptable answers. Why? Not because anybody's declared it, but because we know what you're talking about.
Nope, you are wrong. You do not, in fact, know what you are talking about. You are merely another ignorant idiot.
There are many web pages about this specific issue which you could have read with minimal effort on Google, but you didn't. The ignorant stay ignorant.
Not all plurals are regular in Latin, e.g. corpus corpora. ii is the plural when a noun ends in ius, not us. There is no recorded plural of virus in Latin.
I just use the Turbo Tax web version. I have been using it for a few years now and it works fine.
I never saw a point in installing software I use once a year for an operating system I don't normally run when there is a web version that does the same thing.
I'm so sick of this "it's only less if your time is worth nothing" garbage. For some, it might work, but when you spend hours on slashdot, I can't give you any credit to that statement.
I imagine you'll be doing your taxes by hand then. I suppose you beat your clothing against rocks in the river and hand knit your clothing using wool sheared from sheep you raise in your backyard.
You're preaching to the choir:). I have used Python. I used it for a couple grad classes I took. I have been using it less lately though for work stuff, but I just started playing with Jython which I may have a good use for.
In my experience, Python is at least 5x slower than Java for stuff that's computationally or I/O intensive. At one point I was doing some stuff that involved scanning through a lot of text. I ended up having to rewrite it in Java because the Python version was too slow. I also had to rewrite a Python program I wrote to generate tree structures for testing because it was too slow. The same thing used to happen with Java programs I'd end up rewriting in C. I very rarely write stuff in C anymore.
It depends on the type of stuff you are doing. I agree that it is easy to write concise Python programs. At this point I'm more proficient in Java and have a lot of code lying around I can reuse though.
At work there are very few people that know Perl, let alone Python.
What I haven't tried is this Psyco which is a JIT for Python and supposedly works very well at the expense of using a lot of memory.
I disagree with most of what you wrote except Java admin tools are slow. Your multiple version remarks are not true. I don't think the high cost has nearly as much to do with administration as it does with expensive service contracts required to maintain the hardware.
Sun has great man pages. No, Solaris can't abandon "all of the old stuff". Your mindset is for a home PC, not the bazillions of existing enterprise Solaris apps that will keep running because Sun is smart enough to keep backwards compatibility. GNU/Linux breaks apps far too often. It's ridiculous. The TCO is not as rosy as you think.
Java is hugely successful. Python is neat, but slow and the language changes monthly at the whim of Guido and other developers.
-Kevin
Re:One problem with the argument
on
The Faded Sun
·
· Score: 1
Uh, no.
For starters, it's W, not mW!
Note I am assuming heat dissipation is the same as power consumption, which is roughly true from what I've read.
UltraSPARC IIICu dissipates 65W with the 900 MHz part. The P4 3.06 dissipates 81.8, but the 2.80 only dissipates 68W.
In other words, the CPUs dissipate about the same amount of heat, i.e. use about the same amount of power. Actually to get the same processing power, you would require more UltraSPARCs so it would be more accurate to say Sun is at a power _disadvantage_ here!
-Kevin
Re:Sounds trollish
on
The Faded Sun
·
· Score: 4, Insightful
There is no high end as SGI discovered and Symbolics, Cray, etc. etc. before them.
Of course there's a high end, and there's also a healthy mid-range segment.
Cray is a totally different market really, scientific supercomputing. That market still exists and is as large as ever, it's just not a growth market like PCs. However, the low end is extremely marginalized and hard to profit from.
The CPU speed of Sun hardware is only a small part of the equation in the enterprise market. That you even single it out without talking about I/O, service contracts, or other more important issues, indicates to me that your experience is not in the mid to high end enterprise market.
As protocols goes, FTP is the king for "worst protocol of... mankind"
I'd give my vote to telnet for worst protocol. There are about 40 RFCs specifying the core protocol and options. FTP wins for worst connection model, however.
Use C? Java's advantage to me is a good static vs. dynamic balance, not its raw efficiency. Tons of stuff uses dynamic classloading like JDBC, RMI, and JMX. Developing servlets would really suck without dynamically reloading changed classes. I mean really, semis aren't fuel-efficient commuter cars but they're handy for hauling a lot of stuff.
There is no one size fits all computer language.
I agree that Java is piggish for client apps, but I work on server apps so it's not my concern. I use the Eclipse IDE though which does fairly well.
I don't see why 64 bitness would be an advantage here at all. This is a problem that you'd want running out of cache, not system RAM. From the other posts it does sound like Renderman sucks a lot of memory, so I'd be interested to know what the runtime environment is like.
The 4GB limit you give for x86 isn't correct. P4s can address up to 64GB of physical memory (36 bit address). UltraSparc IIIcu can only address 16GB.
like each individual frame would be an easy break for this
No way, I can't believe they'd render one frame per CPU. Those frames are huge. I bet they break up the frames into dozens (hundreds?) of pieces. Why? Because each frame is much larger than cache and you'd want to keep the working set in cache as much as possible. If you rendered 1024 frames in parallel you'd have to wait for the single CPU time of a frame before you see anything. If you subdivide the render work in the other direction, splitting frames, you would see output much sooner.
Pixar's website gives a render time of 6 hours - 96 hours per frame. An old Sun news release gives a frame size of 1536x922 x 48 bit color, that's about 8 megs/frame.
Considering that compiling Java into a native executable would seriously improve its performance (and remove the JVM requirement), I wonder why the memo doesn't discuss that possibility?
Compiled Java can't do some things at runtime like dynamic classloading. From the benchmarks I've seen, compiled Java is slower.
I think that would be
a step backwards, away from powerful runtime capabilities, and away from the write once run anywhere goal. There are plenty of compiled languages you can use if that is your wish.
Slashdot Mirror
I think they're only focusing on persisting some object state, not replacing databases. Object persistence in a RDBMS is usually done with BLOBs or O/R mapping (putting the state data into tables). OODBMSes have not been very successful the enterprise market.
Discussing the enterprise market is another topic, so I will only discuss this from a technology aspect below.
Persisting objects to RAM is not a new idea. Gemstone made a business out of their persistent cache software for Smalltalk and later Java. There are several researchers looking at reliable distributed data structures like Ninja at Berkeley.
The new idea here seems to be the logging mechanism using the command pattern. It's a big performance boost for writing reliably because you don't have to transactionally synchronize the entire object state to disk, only the changes.
You are right that people like their databases and this doesn't deal with querying, large datasets, and other real world issues.
-Kevin
Yeah, right. Are you new? Just get on the net?
Unless the margin contains a proof of Fermat's Last Theorem, $4,500 for a 15 page report on projected Internet traffic is obscene.
-Kevin
I used to think the same thing about bloat and used FVWM/WindowMaker/whatever, but I've had fewer headaches since switching to KDE a few years ago. I admit some KDE stuff is a bit dorky, but overall it is very well done.
-Kevin
Why do you think you can do a better GUI and make better widgets? You probably can't. Why do I have all these Linux apps with their own widgets and UI paradigm that work poorly? There is no good reason.
People don't want your avant garde hyperdimensional pie menu and mp3 visualizer scrollbar thingy, they just want to be able to use an app instead of fighting it.
-Kevin
-Kevin
Most IM systems are OS agnostic. Do you think MS will publish their protocol?
Finally the P2P update. Well that makes sense really.
It only makes sense when everything is "part of the operating system," i.e. it doesn't make sense since this P2P stuff is used only for three degrees. It may be a good idea to have a P2P OS service in the long run, but P2P protocols really haven't standardized. IIRC Clay Shirky had a good article about lack of standardization being a good thing right now.
Requires Linux 2.5.62 with KDE 3.0 and peer-to-peer upgrade. (with the subtitling that it doesn't run on windows) Would someone have made exactly the same comment?
No, because in all likelihood the Linux app would be open source and not subject to all this proprietary vendor lock in bullshit that MS is famous for.
-Kevin
Nope, you are wrong. You do not, in fact, know what you are talking about. You are merely another ignorant idiot.
There are many web pages about this specific issue which you could have read with minimal effort on Google, but you didn't. The ignorant stay ignorant.
Not all plurals are regular in Latin, e.g. corpus corpora. ii is the plural when a noun ends in ius, not us. There is no recorded plural of virus in Latin.
http://www.m-w.com/wftw/00jan/012800.htm
http://www.wikipedia.org/wiki/Virus
-Kevin
I never saw a point in installing software I use once a year for an operating system I don't normally run when there is a web version that does the same thing.
-Kevin
I imagine you'll be doing your taxes by hand then. I suppose you beat your clothing against rocks in the river and hand knit your clothing using wool sheared from sheep you raise in your backyard.
-Kevin
The OED disagrees with you. Viruses is the plural.
-Kevin
In my experience, Python is at least 5x slower than Java for stuff that's computationally or I/O intensive. At one point I was doing some stuff that involved scanning through a lot of text. I ended up having to rewrite it in Java because the Python version was too slow. I also had to rewrite a Python program I wrote to generate tree structures for testing because it was too slow. The same thing used to happen with Java programs I'd end up rewriting in C. I very rarely write stuff in C anymore.
It depends on the type of stuff you are doing. I agree that it is easy to write concise Python programs. At this point I'm more proficient in Java and have a lot of code lying around I can reuse though.
At work there are very few people that know Perl, let alone Python.
What I haven't tried is this Psyco which is a JIT for Python and supposedly works very well at the expense of using a lot of memory.
-Kevin
Sun has great man pages. No, Solaris can't abandon "all of the old stuff". Your mindset is for a home PC, not the bazillions of existing enterprise Solaris apps that will keep running because Sun is smart enough to keep backwards compatibility. GNU/Linux breaks apps far too often. It's ridiculous. The TCO is not as rosy as you think.
-Kevin
-Kevin
For starters, it's W, not mW!
Note I am assuming heat dissipation is the same as power consumption, which is roughly true from what I've read.
UltraSPARC IIICu dissipates 65W with the 900 MHz part. The P4 3.06 dissipates 81.8, but the 2.80 only dissipates 68W.
In other words, the CPUs dissipate about the same amount of heat, i.e. use about the same amount of power. Actually to get the same processing power, you would require more UltraSPARCs so it would be more accurate to say Sun is at a power _disadvantage_ here!
-Kevin
Of course there's a high end, and there's also a healthy mid-range segment.
Cray is a totally different market really, scientific supercomputing. That market still exists and is as large as ever, it's just not a growth market like PCs. However, the low end is extremely marginalized and hard to profit from.
The CPU speed of Sun hardware is only a small part of the equation in the enterprise market. That you even single it out without talking about I/O, service contracts, or other more important issues, indicates to me that your experience is not in the mid to high end enterprise market.
-Kevin
I'd give my vote to telnet for worst protocol. There are about 40 RFCs specifying the core protocol and options. FTP wins for worst connection model, however.
-Kevin
Jeez, Mozilla's built in download manager and download manager add ins for IE must not exist if you haven't seen them.
-Kevin
-Kevin
-Kevin
I agree that Java is piggish for client apps, but I work on server apps so it's not my concern. I use the Eclipse IDE though which does fairly well.
-Kevin
The 4GB limit you give for x86 isn't correct. P4s can address up to 64GB of physical memory (36 bit address). UltraSparc IIIcu can only address 16GB.
-Kevin
No way, I can't believe they'd render one frame per CPU. Those frames are huge. I bet they break up the frames into dozens (hundreds?) of pieces. Why? Because each frame is much larger than cache and you'd want to keep the working set in cache as much as possible. If you rendered 1024 frames in parallel you'd have to wait for the single CPU time of a frame before you see anything. If you subdivide the render work in the other direction, splitting frames, you would see output much sooner.
Pixar's website gives a render time of 6 hours - 96 hours per frame. An old Sun news release gives a frame size of 1536x922 x 48 bit color, that's about 8 megs/frame.
-Kevin
Compiled Java can't do some things at runtime like dynamic classloading. From the benchmarks I've seen, compiled Java is slower.
I think that would be a step backwards, away from powerful runtime capabilities, and away from the write once run anywhere goal. There are plenty of compiled languages you can use if that is your wish.
-Kevin
But not kernel forks which is what Net/Open/Free BSD are.
-Kevin
-Kevin