Really, try Zope. Yes, it's a little bit of a learning courve, but (and I did all of them for a living) it be beats Java/Tomcat/Struts and PHP hands down in productivity/maintainability once you get a grip on it.
LOL, this is quite funny. I thought Zeta would sell quite well, because I figured otherwise the TV shows would've stopped selling it. Hmm, when some of the big german computer magazines (c't etc.) notice what you are pointing out here (big problems with even installing Zeta for the average Joe), the desaster for yellowTab might be not too far off. Maybe you can give them a hint;).
The submitted story seems to be not reflect reality. In fact, Zeta is already sold since several months - in a shopping tv show!. Look here.. The page is in german, but you'll see a link to zeta on the lower right side of the page. And they even call it a bestseller. Though this could be a lie, I doubt they'd pitch it for so long if it wouldn't sell.
I saw the sales pitch, and it is very interesting how the strategy of "real" salesmen is for selling this to the great unwashed masses. Virus free, some nice demonstrations of the multimedia capabilites, the office software etc. etc., and always pointing out the fact that it works on older computers without problems and that it's much cheaper than windows+ms office+...
While your example might not be right, I completely agree with you and can only encourage you to proceed looking into python. I've read and worked on relativly big projects in python like zope, and I have come to the conclusion that the arguments for static typing, while valid, might focus on a too small subset of the task of getting a solid program done. What I mean is, yes, static typing gives you some guiding, but on the other hand, it seems to have the effect that the developers might "not see the wood for the trees". In fact, I've very seldom seen things go wrong for lack of type checking in python, but I've seen java programmers fiddling around trying to pass the right types to methods, and then find out that the application still didn't do what it should because something else went wrong. In a language like python, OTOH, it seems that because you are not forced to spend your time thinking about these syntactical issues, you are concentrating more on thinking about the code from a functional POV, which seems to lead to getting the typing right anyway.
I'd say that the problem is that many home users have the choice between a pirated MS Office (or more seldomly a OEM version supplied with the computer) vs. a free version of OOo. Many choose the pirated version, because they somehow, strangely, perceive this as being better from a price-feature POV - don't ask me why.
And if you are doing that, Niagara won't help you one bit. Because if your thread is blocking, it can be scheduled anyway by the OS even on a singe CPU machine and another thread can run. On Niagara, you would just put one core into waiting state - ergo, no speedup.
No, Sun is using this technique as a last resort, because POWER5 and x86(-64) architectures are destroying everything Sparc has come up with since the last several years. God damn, I wish people would take a look at the normal performance characteristics of their servers (or even PCs). In most cases there are just one or two threads (processes) dominating CPU usage. Niagara won't help you there.
And in the end, it's about raw speed. Even Sun's charts I saw a some time ago did only show an advantage for Niagara in around 2007. And it was very optimistic in it's projection for the speed of Niagara, and quite pessimistic in forecasting the speed of rival processors - and totally neglected that AMD, Intel or IBM also could also achieve combining multiple chips on one core if there is a market for that. And all this combined with the questionable target problem field of such an architecture.
One must not forget that competing CPUs are a) much faster core-for-core b) probably also much more cost efficient concerning (single core speed)/cost.
Unfortunately, massively multihreaded uses are a small field between heavily parallizable and non-parallizable problems. And in both of these areas, SUN gets destroyed by x86(64) or POWER5 architectures, either as standalone, or as SMP or cluster architectures. This niagara thing is nothing more than Sun's contrived way of conceding they (or SPARC) lost the processor war.
If you're just transporting data from one relational database server to another, use a flat file, or better yet raw SQL dumps.
You are narrowing down the aspect of transporting data too much. The most aspects of transporting data is not between db servers (with the same db schemas) but between application servers, which might use relational databases as their backend to store data - but in totally different schemas.
So, you want to exchange data not between the database backends - whose db structure you might not even have under control, there are a lot of applications out there which totally abstract away the database and create need/create/maintain their own structure in the database - but between the app servers, where the knowledge about the data semantics is and where you want to implement the mapping. And if you are looking for how to sanely exchange data between the applications, XML can be very handy, especially if you don't control all of the involved applications. That way you can very strictly specify the message structure with XML Schemas and implementations in the different applications can be verified to a large extend without having to connect the applications, just by using the Schematas.
the old versions of each article are already achieved, what you'd need to have is a permanent link to the current page which would always lead to _that_ specific version, even if the page gets updated. Everything else is there (look at the history tab of an article). I don't know if the link to a version is static over time, but I think it ought to be. The result would be a much more sophisticated version of what you rightly propose, i.e. version specific to each article. About the review&revisal process for these snapshots, that would make no sense, because you'd have to invest a lot of manpower to do this - and you'd have to make sure that the reviewers are more "reliable" than the average wikipedia editor who does exactly this job regularly.
The probability of global warming - as another poster has already written - is 1. But that's not what I wrote, you might want to reread what I said. There's a plethora of possible consequences predicted from it, and nearly nobody denies that some of these will indeed occur (we can also observe some of them today). Each of these will impact more people than this asteroid, the question is how. See for instance http://www.gcrio.org/CONSEQUENCES/summer95/agricul ture.html or other articles on that page.
Well, given reaction on global warming, which has a much higher probability to considerably impact the lifes of millions of people in roughly the same timespan, it might be interesting compare. Ok, we don't need to stop driving obscenly oversized cars to avoid this catastrophy.
I don't think it's so easy. While you are right that in deep water, the energy of the earthquake was distributed across a very long wave with a very low amplitude (i.e. big wavelength, sic), the shallower shore acted as a kind of "lense", concentrating the energy to a smaller area (shorter wavelength, higher amplitude). I assume an asteroid might cause waves with shorter wavelengths even in deep water, but OTOH there'd be not such a "lense effect". In the end, the product of amplitude, wavelength and the square of the speed of the wavefront determines the energy, so waves being taller in deep water does not mean they'll be more destructive when hitting the shore - i.e. the earthquake causes the whole of the sea to "move", while an asteroid might mainly impact the surface. Since at around 800 km/h, wind resistance is a real factor, higher waves might even be considerably dampened on their way through the sea.
This was the first link after I put "jabber whiteboard" into google...
Re:Python, prototyping, and gmailfs
on
Dive Into Python
·
· Score: 1
I'd say that FUSE, which is the other package gmailfs is very dependend on, is even a bigger programming venture. One day I'll have to take a sharp look at it.
And you know what? If people would license Oracle only for Mission Critical Apps and large DBs, Oracle would be bankrupt tomorrow. At least if I extrapolate what I'm seeing in the enterprise, Oracle's total revenue would go down 80%. That's why they were already FUDing around in 2002 when the decision about the.org domains was made (hardly something which would justify paying $$$ to Oracle).
They are doing marketing quite extensively, for instance in the Formula 1 with Ferrari, in Cycling they sponsor USPS (Lance Armstrong). Ironically, they seem to also be picking the winner in sponsoring atm (intel is also in the F1).
I do think it's a bit silly though, all this technology used to colonise mars and the best solution they can come up with is a old style flashlight (what about infra red nightvision ?)
Well, infra red also needs an active light source - which is just invisible for normal eyes. But you can't expect your enemies not also to be able to see that infrared light - especiall if they come from hell.
Slashdot Mirror
Really, try Zope.
Yes, it's a little bit of a learning courve, but (and I did all of them for a living) it be beats Java/Tomcat/Struts and PHP hands down in productivity/maintainability once you get a grip on it.
LOL, this is quite funny. ;).
I thought Zeta would sell quite well, because I figured otherwise the TV shows would've stopped selling it.
Hmm, when some of the big german computer magazines (c't etc.) notice what you are pointing out here (big problems with even installing Zeta for the average Joe), the desaster for yellowTab might be not too far off. Maybe you can give them a hint
If you're from germany, you might know this..
Look at the right lower side of the page.
The submitted story seems to be not reflect reality.
In fact, Zeta is already sold since several months - in a shopping tv show!. Look here..
The page is in german, but you'll see a link to zeta on the lower right side of the page. And they even call it a bestseller. Though this could be a lie, I doubt they'd pitch it for so long if it wouldn't sell.
I saw the sales pitch, and it is very interesting how the strategy of "real" salesmen is for selling this to the great unwashed masses. Virus free, some nice demonstrations of the multimedia capabilites, the office software etc. etc., and always pointing out the fact that it works on older computers without problems and that it's much cheaper than windows+ms office+...
All very interesting.
It works for me, I've not changed it. So what's your excuse?
Postgres
SCNR
How about a whole show full of Wesley Crusher teen angst in a Federation uniform.
;).
godamn, this is exactly what came to my mind when I read the story. Waaah!
Maybe Mr. Wheaton is around to comment what he thinks of that idea
While your example might not be right, I completely agree with you and can only encourage you to proceed looking into python.
I've read and worked on relativly big projects in python like zope, and I have come to the conclusion that the arguments for static typing, while valid, might focus on a too small subset of the task of getting a solid program done.
What I mean is, yes, static typing gives you some guiding, but on the other hand, it seems to have the effect that the developers might "not see the wood for the trees". In fact, I've very seldom seen things go wrong for lack of type checking in python, but I've seen java programmers fiddling around trying to pass the right types to methods, and then find out that the application still didn't do what it should because something else went wrong.
In a language like python, OTOH, it seems that because you are not forced to spend your time thinking about these syntactical issues, you are concentrating more on thinking about the code from a functional POV, which seems to lead to getting the typing right anyway.
I'd say that the problem is that many home users have the choice between a pirated MS Office (or more seldomly a OEM version supplied with the computer) vs. a free version of OOo. Many choose the pirated version, because they somehow, strangely, perceive this as being better from a price-feature POV - don't ask me why.
And if you are doing that, Niagara won't help you one bit. Because if your thread is blocking, it can be scheduled anyway by the OS even on a singe CPU machine and another thread can run. On Niagara, you would just put one core into waiting state - ergo, no speedup.
No, Sun is using this technique as a last resort, because POWER5 and x86(-64) architectures are destroying everything Sparc has come up with since the last several years.
God damn, I wish people would take a look at the normal performance characteristics of their servers (or even PCs). In most cases there are just one or two threads (processes) dominating CPU usage. Niagara won't help you there.
And in the end, it's about raw speed. Even Sun's charts I saw a some time ago did only show an advantage for Niagara in around 2007. And it was very optimistic in it's projection for the speed of Niagara, and quite pessimistic in forecasting the speed of rival processors - and totally neglected that AMD, Intel or IBM also could also achieve combining multiple chips on one core if there is a market for that. And all this combined with the questionable target problem field of such an architecture.
One must not forget that competing CPUs are a) much faster core-for-core b) probably also much more cost efficient concerning (single core speed)/cost.
Unfortunately, massively multihreaded uses are a small field between heavily parallizable and non-parallizable problems. And in both of these areas, SUN gets destroyed by x86(64) or POWER5 architectures, either as standalone, or as SMP or cluster architectures.
This niagara thing is nothing more than Sun's contrived way of conceding they (or SPARC) lost the processor war.
If you're just transporting data from one relational database server to another, use a flat file, or better yet raw SQL dumps.
You are narrowing down the aspect of transporting data too much. The most aspects of transporting data is not between db servers (with the same db schemas) but between application servers, which might use relational databases as their backend to store data - but in totally different schemas.
So, you want to exchange data not between the database backends - whose db structure you might not even have under control, there are a lot of applications out there which totally abstract away the database and create need/create/maintain their own structure in the database - but between the app servers, where the knowledge about the data semantics is and where you want to implement the mapping.
And if you are looking for how to sanely exchange data between the applications, XML can be very handy, especially if you don't control all of the involved applications. That way you can very strictly specify the message structure with XML Schemas and implementations in the different applications can be verified to a large extend without having to connect the applications, just by using the Schematas.
WLAN Hotspots are dead easy to use. If you are a T-Mobile Customer, you can order WLAN time via SMS.
I expect this to be possible on the train too.
Well,
the old versions of each article are already achieved, what you'd need to have is a permanent link to the current page which would always lead to _that_ specific version, even if the page gets updated. Everything else is there (look at the history tab of an article).
I don't know if the link to a version is static over time, but I think it ought to be.
The result would be a much more sophisticated version of what you rightly propose, i.e. version specific to each article.
About the review&revisal process for these snapshots, that would make no sense, because you'd have to invest a lot of manpower to do this - and you'd have to make sure that the reviewers are more "reliable" than the average wikipedia editor who does exactly this job regularly.
The probability of global warming - as another poster has already written - is 1. But that's not what I wrote, you might want to reread what I said.l ture.html
There's a plethora of possible consequences predicted from it, and nearly nobody denies that some of these will indeed occur (we can also observe some of them today). Each of these will impact more people than this asteroid, the question is how.
See for instance http://www.gcrio.org/CONSEQUENCES/summer95/agricu
or other articles on that page.
Well, given reaction on global warming, which has a much higher probability to considerably impact the lifes of millions of people in roughly the same timespan, it might be interesting compare.
Ok, we don't need to stop driving obscenly oversized cars to avoid this catastrophy.
I don't think it's so easy. While you are right that in deep water, the energy of the earthquake was distributed across a very long wave with a very low amplitude (i.e. big wavelength, sic), the shallower shore acted as a kind of "lense", concentrating the energy to a smaller area (shorter wavelength, higher amplitude).
I assume an asteroid might cause waves with shorter wavelengths even in deep water, but OTOH there'd be not such a "lense effect".
In the end, the product of amplitude, wavelength and the square of the speed of the wavefront determines the energy, so waves being taller in deep water does not mean they'll be more destructive when hitting the shore - i.e. the earthquake causes the whole of the sea to "move", while an asteroid might mainly impact the surface.
Since at around 800 km/h, wind resistance is a real factor, higher waves might even be considerably dampened on their way through the sea.
This was the first link after I put "jabber whiteboard" into google ...
I'd say that FUSE, which is the other package gmailfs is very dependend on, is even a bigger programming venture. One day I'll have to take a sharp look at it.
all you'd have to do is heat it and boom its all scrambled
Ever observed an old fashioned CD ROM in a running microwave?
And you know what? If people would license Oracle only for Mission Critical Apps and large DBs, Oracle would be bankrupt tomorrow. .org domains was made (hardly something which would justify paying $$$ to Oracle).
At least if I extrapolate what I'm seeing in the enterprise, Oracle's total revenue would go down 80%. That's why they were already FUDing around in 2002 when the decision about the
They are doing marketing quite extensively, for instance in the Formula 1 with Ferrari, in Cycling they sponsor USPS (Lance Armstrong). Ironically, they seem to also be picking the winner in sponsoring atm (intel is also in the F1).
I do think it's a bit silly though, all this technology used to colonise mars and the best solution they can come up with is a old style flashlight (what about infra red nightvision ?)
Well, infra red also needs an active light source - which is just invisible for normal eyes. But you can't expect your enemies not also to be able to see that infrared light - especiall if they come from hell.
Do LCDs with 1600x1200 and 12ms response time even exist?